Как упаковать программу в exe visual studio

Если вы начинающий разработчик или вам нужно скомпилировать ваш проект в Visual Studio 2012 и создать .exe файл, эта статья для вас.

Шаг 1: Создание проекта

Перед тем, как начать компилировать проект, вам нужно создать его. Для этого откройте Visual Studio 2012 и выберите File -> New -> Project. Затем выберите тип проекта, который вы хотите создать, и нажмите OK.

Шаг 2: Настройка проекта

Для того, чтобы скомпилировать проект в .exe файл, необходимо внести некоторые изменения в его настройки. В меню слева выберите Configuration Properties -> General, и установите значение “Configuration Type” равным “Application (.exe)”.

Шаг 3: Сборка проекта

Чтобы скомпилировать проект, нажмите на клавиатуре клавишу F7 или перейдите в меню Build -> Build Solution. Это начнет сборку проекта.

Шаг 4: Поиск .exe файла

После того, как проект был успешно скомпилирован, .exe файл может находиться в папке Debug (если вы использовали Debug конфигурацию) или в папке Release (если вы использовали Release конфигурацию).

Create .exe file in visual studio | Generate exe file from project in visual studio 2019 c++ c java

Шаг 5: Запуск .exe файла

Чтобы запустить .exe файл, дважды щелкните по нему.

В заключение, сборка проекта в Visual Studio 2012 и создание .exe файла может показаться сложным на первый взгляд, но при следовании этим пяти простым шагам это может быть осуществлено без проблем. Начните создавать и собирать свои проекты в Visual Studio 2012 сегодня!

Источник: xn—-dtbibpfbbf1bhels.xn--p1ai

C#: сборки (Assemblies)

Сборка представляет собой одиночный файл Portable Executable (PE) с расширением .exe в случае приложения или .dll в случае многократно используемой библиотеки.

Содержимое сборки

• Манифест сборки — содержит сведения для исполняющей среды .NET: имя сборки, версия, необходимые права доступа, ссылки на другие сборки.
• Манифест приложения — содержит сведения для операционной системы: способ развертывания сборки, необходимость администраторских полномочий.
• Скомпилированный типы — скомпилированный код IL и метаданные типов, включенных в сборку.
• Ресурсы — другие данные, включенные в сборку: изображения, локализуемые тексты.

Обязательным является только манифест сборки (хотя как правило содержатся скомпилированные типы. Исполняемые файлы и библиотеки имеют одинаковую структуру, основное отличие в том, что исполняемые файлы содержат точку входа.

Манифест сборки

Манифест сборки обязательно должен содержать:

• простое имя сборки
• номер версии ( AssemblyVersion )
• открытый ключ и подписанный хэш сборки, если она имеет строгое имя
• список ссылаемых сборок (включая их версии и открытые ключи)
• список модулей сборки
• список типов, определенных в сборке, и модулей, содержащих каждый тип
• необязательный набор прав доступа, требуемых или отклоняемых сборкой ( SecurityPermission )
• целевая культура если это подчиненная сборка ( AssemblyCulture )

Также манифест сборки может содержать:

Generate EXE File from C# Project in Visual Studio 2019

• полный заголовок и описание ( AssemblyTitle и AssemblyDescription )
• копирайт и информацию о компании ( AssemblyCompany и AssemblyCopyright )
• дополнительные сведения о версии ( AssemblyInformationalVersion )
• дополнительные атрибуты для специальных данных

Некоторые из этих данных выводятся из параметров, переданных компиляторы. Остальные берутся из атрибутов сборки (указаны в скобках):

[ assembly : AssemblyCopyright ( «x00a9 Corp Ltd. All rights reserved.» ) ]
[ assembly : AssemblyVersion ( «2.3.2.1» ) ]

Атрибуты сборки обычно определяются в одном файле в проекте. Visual Studio, например, автоматически создает для этих целей файл AssemblyInfo.cs в папке Properties в каждом проекте и заполняет его начальной информацией.

Манифест приложения

Манифест приложения — это XML-файл, который сообщает информацию о сборке операционной системе. Если он определен, он обрабатывается перед загрузкой сборки и может повлиять на запуск процесса приложения со стороны ОС.

Корневой элемент манифеста — assembly в пространстве имен urn:schemas-microsoft-com:asm.v1 :

С помощью следующего примера можно затребовать прав администратора для приложения:

Манифест приложения может быть как отдельным файлом, так и встроенным в саму сборку. Как отдельный файл он должен находиться в одной папке с самой сборкой и иметь расширение .manifest (например, для сборки MyApp.exe — MyApp.exe.manifest ).

Встроить манифест в саму сборку (для этого ее надо сначала скомпилировать) можно с помощью утилиты mt такой командой:

mt — manifest MyApp . exe . manifest — outputresource : MyApp . exe ; #1

Модули

Содержимое сборки на самом деле упаковано в один или несколько контейнеров, называемых модулями. Модуль соответствует одному файлу сборки и дает возможность создавать сборки, состоящие из нескольких файлов. В многофайловой сборке главный модуль всегда содержит манифест, а дополнительные модули могут содержать код и/или ресурсы. Манифест описывает относительное местоположение всех модулей сборки.

Класс Assembly

Класс System.Reflection.Assembly позволяет получить доступ к метаданным сборки во время выполнения. Получить объект сборки можно несколькими способами:

с помощью свойства Assembly класса Type :

Assembly a = typeof ( Program ) . Assembly ;

• GetExecutingAssembly — возвращает сборку, содержащую выполняемую функцию (метод)
• GetCallingAssembly — возвращает сборку, содержащую функцию, которая вызвала текущую выполняемую функцию
• GetEntryAssembly — возвращает сборку, содержащую точку входа в приложение

Получив объект Assembly с помощью его методов и свойств можно получить метаданные сборки и выполнять рефлексию ее типов.

Члены класса Assembly :

• FullName , GetName — возвращает полностью заданное имя или объект AssemblyName
• CodeBase , Location — местоположение файла сборки
• Load , LoadFrom , LoadFile — вручную загружает сборку в текущий домен приложения
• GlobalAssemblyCache — указывает, находится ли сборка в GAC
• GetSatelliteAssembly — находит подчиненную сборку с заданной культурой
• GetType , GetTypes — возвращает тип или все типы, определенные в сборке
• EntryPoint — возвращает метод точки входа в приложение как объект MethodInfo
• GetModules , ManifestModule — возвращает все модули или главный модуль сборки
• GetCustomAttributes — возвращает атрибуты сборки

Имена сборок

Идентификатор сборки состоит из четырех частей:

• простое имя
• версия («0.0.0.0» если не задана)
• культура («neutral» для не подчиненных сборок)
• маркер открытого ключа («null» если сборка не имеет строгого имени)

Простое имя берется из имени файла, в который сборка была первоначально скомпилирована. Расширение отбрасывается, например, простое имя для сборки System.Xml.dll выглядит как System.Xml . Переименование файла не изменяет простое имя сборки.

Номер версии берется из атрибута AssemblyVersion и представляет собой строку, разделенную на 4 части:

major . minor . build . revision
старший _ номер . младший _ номер . компоновка . редакция

Задать номер версии можно так:

[ assembly : AssemblyVersion ( «2.5.6.7» ) ]

Культура берется из атрибута AssemblyCulture и применяется к подчиненным сборкам.

Маркер открытого ключа берется из пары ключей, передаваемых компилятору с помощью параметра /keyfile .

Полностью заданные имена (Fully Qualified Names)

Полностью заданное имя сборки — это строка, включающая все 4 идентифицирующих компонента в следующем формате:

простое _ имя , Version =версия , Culture =культура , PublicKeyToken =открытый _ ключ

Например, для сборки System.Xml.dll :

«System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089»

Класс AssemblyName

Класс AssemblyName содержит свойства для каждого из 4 компонентов полностью заданного имени. Получить объект AssemblyName можно несколькими способами:

• создать экземпляр типа AssemblyName , передав ему полностью заданное имя; можно также создать экземпляр не передавая конструктору аргументов, а затем установить все свойства вручную (в этом случае объект AssemblyName будет изменяемым)
• вызвать метод GetName объекта Assembly
• вызвать метод AssemblyName.GetAssemblyName , передав ему путь к файлу сборки

Основные свойства и методы объекта AssemblyName :

string FullName < get ; >// Полностью заданное имя
string Name < get ; set ; >// Простое имя
Version Version < get ; set ; >// Версия
CultureInfo CultureInfo < get ; set ; >// Для подчиненных сборок
string CodeBase < get ; set ; >// Местоположение
byte [ ] GetPublicKey ( ) ; // Открытый ключ
void SetPublicKey ( byte [ ] key ) ;
byte [ ] GetPublicKeyToken ( ) ; // Последние 8 байт открытого ключа
void SetPublicKeyToken ( byte [ ] publicKeyToken ) ;

Свойство Version возвращает объект типа Version , который сам обладает свойствами Major , Minor , Build и Revision . Поскольку версия сборки, задаваемая атрибутом AssemblyVersion , является частью имени сборки, ее изменение в некоторых случаях не желательно. Помимо атрибута AssemblyVersion существуют еще два атрибута задающие версию,но носящие чисто информативный характер и никак не учитываемые средой CLR:

• AssemblyInformationalVersion — информационная версия — задает версию, отображаемую конечному пользователю. Она видна в диалоговом окне свойств файла в поле Product Version (Версия продукта). Здесь может находиться любая строка, например, 5.1 Beta 2 . Обычно все сборки в приложении имеют одинаковую информационную версию.
• AssemblyFileVersion — файловая версия — ссылается на номер компоновки (build) сборки. Отображается в диалоговом окне свойств файла в поле File Version (Версия файла). Как и AssemblyVersion должна содержать строку разделенную на 4 части.

Строгие имена (Strong Names)

Строгие имена помогают защитить сборку от подделки. Строго именованная сборка имеет уникальный и не подделываемый идентификатор, что достигается путем добавления в манифест сборки следующих метаданных:

• уникальный номер, принадлежащий автору сборки
• подписанный хэш сборки, доказывающий, что сборка создана владельцем уникального номера

Достигается это с помощью пары открытого и секретного ключей. Открытый ключ как раз и представляет собой уникальный номер автора; он указывается в полностью заданном имени сборки. Секретный ключ используется для создания подписанного хэша.

Чтобы назначить сборке строгое имя необходимо сначала сгенерировать файл с парой ключей, например, с помощью утилиты sn.exe. Утилита создаст файл с расширением .snk, содержащий пару ключей. Затем сборку нужно скомпилировать с параметром /keyfile:

csc . exe / keyfile : MyKeyPair . snk Program . cs

В Visual Studio эти два шага можно проделать проще с помощью окна Свойства проекта.

Подпись Authenticode

Строгие имена сборок позволяют установить, что они принадлежат одному автору, но не дают возможности узнать кому именно. Система подписания кода Authenticode как раз позволяет установить, кто именно является автором сборки.

Чтобы добавить к сборке такую подпись необходимо, во-первых, получить сертификат для подписания кода в центре сертификации (услуга платная) и установить его в системе, а затем подписать сборку с помощью утилиты signtool.exe.

Windows автоматически при первом запуске проверяет подпись Authenticode, однако это можно сделать и программно:

Publisher p = someAssembly . Evidence . GetHostEvidence < Publisher >( ) ;

Класс Publisher в пространстве имен System.Security.Policy содержит свойство Certificate. Если это свойство возвращает значение отличное от null, значит сборка подписана системой Authenticode.

Подпись Authenticode не является частью имени сборки.

GAC — глобальный кэш сборок (Global Assembly Cache)

При установке .NET Framework создает на компьютере централизованный репозиторий сборок — глобальный кэш сборок (Global Assembly Cache — GAC). GAC содержит сборки самой платформы .NET Framework, и в него также можно добавлять собственные сборки. Основной особенностью GAC является централизованная поддержка версий (управляется администратором на уровне машины). Если такая поддержка действительно нужна, можно добавить сборки в GAC, во всех остальных случаях это только усложнит разработку. развертывание и поддержку приложения.

Чтобы установить сборку в GAC ей прежде всего нужно задать строгое имя. После этого ее можно добавить в GAC с помощью утилиты gacutil :

gacutil / i MyAssembly . dll

Если в GAC уже существует сборка с тем же самым открытым ключом и версией — она обновиться. Если версия сборки отличается от установленной в GAC, то новая сборка будет установлена параллельно, при этом старые приложения будут ссылаться на старую сборку, а в новых приложения можно будет выбирать с какой версией сборки им работать.

Удалить сборку можно следующей командой:

gacutil / u MyAssembly

Установку сборок в GAC можно задать как часть проекта установки в Visual Studio.

После загрузки сборки в GAC приложения могут ссылаться на нее, не нуждаясь в локальной копии. При этом если локальная копия присутствует, она будет проигнорирована в пользу сборки из GAC.

Ресурсы

Сборка помимо исходного кода может содержать ресурсы: текст, изображения и XML-файлы. Обычно в качестве ресурсов в сборку добавляются изображения или локализуемые данные. Ресурс сборки в конечном итоге представляет собой байтовый поток с именем. Сборка хранит их в словарях со строковыми ключами.

Локализуемое содержимое сначала добавляется в файлы .resources . При компиляции они упаковываются как индивидуальные подчиненные сборки, которые автоматически выбираются во время выполнения на основе языка ОС.

Непосредственное встраивание ресурсов

Чтобы встроить ресурс напрямую в сборку нужно скомпилировать ее с одним или несколькими параметрами /resource :

csc / resource : banner . jpg / resource : data . xml MyApp . cs

При этом можно задать другое имя для ресурса:

csc / resource : < имя-файла >, < имя-ресурса >

В Visual Studio для добавления ресурса в сборку нужно добавить файл к проекту и установить для него в качестве действия сборки Embedded Resource ( Встроенный ресурс ). Visual Studio всегда предваряет имя ресурса стандартным пространством имен проекта и именами всех подпапок, в которых находится файл (через точку). Имена ресурсов чувствительны к регистру.

Для извлечения ресурса вызывается метод GetManifestResourceStream объекта сборки, содержащей ресурс. Метод возвращает поток:

Assembly a = Assembly . GetEntryAssembly ( ) ;
// для XML-файла:
using ( Stream s = a . GetManifestResourceStream ( «TestProject.data.xml» ) )
using ( XmlReader r = XmlReader . Create ( s ) )
// для изображения:
System . Drawing . Image image ;
using ( Stream s = a . GetManifestResourceStream ( «TestProject.banner.jpg» ) )
image = System . Drawing . Image . FromStream ( s ) ;

Метод GetManifestResourceNames возвращает имена всех ресурсов сборки.

Локализуемые данные

Локализуемые данные добавляются в сборку с помощью файлов .resources , которые в конечном итоге добавляются в сборку как встроенные ресурсы точно также как и остальные файлы.

Эти файлы являются двоичными и редактировать их непосредственно нельзя. Поэтому обычно на этапе разработки создаются файлы .resx , которые затем с помощью Visual Studio или утилиты resgen преобразуются в файлы .resources (которые в свою очередь уже встраиваются в сборку).

Файл .resx использует XML и структурирован в виде пар имя-значение:

Файл .resx можно создать с помощью Visual Studio, добавив в проект элемент типа Resources File ( Файл ресурсов ). Visual Studio сама создаст корректную структуру файла, а в дальнейшем автоматически преобразует его в файл .resources и встроит в сборку при компиляции.

Также при создании файла .resx Visual Studio автоматически создает класс с тем же именем; этот класс имеет свойства для извлечения каждого элемента. Однако можно работать с данными из файла .resources и напрямую, с помощью класса ResourceManager . Класс содержит два метода GetString и GetObject , возвращающие конкретный элемент ( GetObject следует использовать с приведением):

ResourceManager r = new ResourceManager ( «welcome» , Assembly . GetExecutingAssembly ( ) ) ;
string greeting = r . GetString ( «Greeting» ) ;
int fontSize = ( int ) r . GetObject ( «DefaultFontSize» ) ;
Image image = ( Image ) r . GetObject ( «flag.png» ) ; // Visual Studio
byte [ ] imgData = ( byte [ ] ) r . GetObject ( «flag.png» ) ; // Командная строка

Подчиненные сборки

Локализация данных осуществляется с помощью подчиненных сборок. Подчиненные сборки содержат локализованные файл .resources , переведенные на различные языки. При этом основная сборка должна содержать файл .resources для языка по умолчанию. Когда приложение запускается, платформа .NET выясняет язык текущей ОС, и каждый раз при обращении к классу ResourceManager платформа ищет соответствующую локализованную сборку. Если она найдена и содержит соответствующий ключ ресурса, она будет использована вместо главной сборки, в противном случае будет использована версия из главной сборки.

Подчиненная сборка не может содержать исполняемого кода, а только локализованные ресурсы. Подчиненные сборки развертываются в подкаталогах папки сборки:

programBaseFolder MyProgram . exe
MyLibrary . exe
XX MyProgram . resources . dll
XX MyLibrary . resources . dll

Здесь XX — двухбуквенный код языка (например, de ) либо код языка и региона (например, en-GB ).

Чтобы добавить подчиненную сборку нужно добавить в проект еще один файл .resx , название которого должно содержать код локализации (отделенный точкой), например, welcome.de.resx . При компиляции в Visual Studio будет автоматически создан подкаталог (например, de ), а в нем подчиненная сборка (например, MyApp.resources.dll ).

Культуры

Культуры разделяются на собственно культуры и подкультуры. культура представляет конкретный язык, а подкультура — региональный вариант этого языка. Культура обозначается с помощью двухбуквенного кода (например, en , de ), а подкультуры — с помощью четырехбуквенного( en-AU , de-AT ).

В .NET культура представлена классом System.Globalization.CultureInfo . Текущую культуру можно получить следующим способом:

Console . WriteLine ( System . Threading . Thread . CurrentThread . CurrentCulture ) ;
Console . WriteLine ( System . Threading . Thread . CurrentThread . CurrentUICulture ) ;

Свойство CurrentCulture отражает региональные настройки Windows, а свойство CurrentUICulture — язык пользовательского интерфейса.

Разрешение сборок

Обычно приложение состоит из основной исполняемой сборки (.exe) и нескольких связанных библиотечных сборок (.dll). Разрешение сборок — это процесс нахождения сборок, на которые производится ссылка. Оно происходит как на этапе компиляции, так и во время выполнения. На этапе компиляции компилятору известно, где находится ссылаемая сборка, поскольку разработчик (или Visual Studio) предоставляет полный путь к сборкам, находящимся вне текущего каталога.

Во время выполнения схема несколько сложнее. При первом обращении к какому либо типу CLR сначала определяет, находится ли он в текущей сборке или во внешней. Если тип находится во внешней сборке, CLR проверяет загружена ли уже эта сборка в память. Если сборка не загружена, CLR пытается ее найти.

Первым делом проверяется GAC, затем базовый каталог приложения и другие пути поиска (если заданы). Если сборку найти не удалось, генерируется событие AppDomain.AssemblyResolve , которое можно перехватить и загрузить сборку вручную. Если после этого сборка все равно не найдена CLR генерирует исключение.

Событие AssemblyResolve

Событие AssemblyResolve позволяет вмешаться в процесс и вручную загрузить сборку. Внутри обработчика события AssemblyResolve производится поиск сборки и ее загрузка с помощью одного из статических методов класса Assembly : Load , LoadFrom или LoadFile . Эти методы возвращают ссылку на загруженную сборку, и эта ссылка, в свою очередь, возвращается вызывающему коду:

Источник: devkazakov.com

Как упаковать программу в exe visual studio

Я не очень большой фанат компании Microsoft, однако следует признать, что они сделали действительно потрясающую среду разработки Visual Studio. Особенно мне нравится в Visual Studio фича intellisense, которая автоматически дает подсказки по именам членов классов, функциям и полям структур, и для проектов AVR большого размера действительно предпочтительнее использовать Visual Studio IDE в сравнении с простым текстовым редактором.

Здесь приведена краткая инструкция (перевод статьи [1]) — как настроить среду Visual Studio 2008/2010 для использования тулчейна WinAVR и компилирования Ваших программ AVR для получения файлов в формате Intel Hex [2] (прошивка кода firmware микроконтроллера). Этот формат подходит для загрузки программы в память AVR/Arduino с использованием AVRDUDE и/или другого Вашего программатора (например, USBasp, AVRISP-mkII, JTAGICE mkII [3]).

Примечание: предполагается, что у Вас уже установлены тулчейн AVR GCC (в составе пакета WinAVR или Atmel Studio), и конечно же среда разработки Microsoft Visual Studio.

[Шаг 1. Создание Makefile-проекта]

Запустите Visual Studio, зайдите в меню Файл -> Создать -> Проект. выберите раздел Установленные шаблоны -> Visual C++ -> Проект, использующий makefile:

Введите имя проекта (Имя:), выберите папку, где будет расположен каталог проекта (Расположение:), уберите галочку «Создать каталог для решения», кликните OK.

Запустится мастер настройки проекта (см. скриншоты).

Настройте в окне «Параметры конфигурации отладки» следующие опции:

1. Командная строка построения: make

2. Команды очистки: make clean

3. Командная строка перестроения: make all

Примечание: можно ввести список команд, по одной в строке списка. В качестве команды перестроения здесь введены 2 команды, которые будут выполнены друг за другом:

make clean make

4. Вывод (для отладки): имя для выходного файла прошивки. Обязательно укажите расширение файла *.hex (GenericHID.hex, к примеру).

5. Путь поиска включений: %AVR32_HOME%avrinclude

Примечание: здесь %AVR32_HOME% это переменная окружения, в которой задан каталог установки WinAVR (например, C:WinAVR-20100110) или тулчейна из Atmel Studio (например, c:Program FilesAtmelAVR ToolsAVR Toolchain). Вместо переменной окружения можно указать просто реальный путь до тулчейна.

Кликните Далее. В окне «Параметры конфигурации выпуска» поставьте галочку «Как в конфигурации отладки». Кликните Готово.

[Шаг 2. Сконфигурируйте проект]

Среда Visual Studio автоматически создала для Вас пустой makefile-проект. Теперь его нужно немного настроить, чтобы можно было начать писать программу для AVR.

Сделайте правый клик на названии проекта (myAVRproj) в дереве Обозревателя решений, и выберите в контекстном меню Свойства. Откроется окно редактирования свойств проекта с активной конфигурацией Debug.

В разделе Свойства конфигурации -> Общие из выпадающего списка «Поддержка общеязыковой среды выполнения (CLR)» (Common Language Runtime Support (/clr)) выберите вариант Поддержка общеязыковой среды выполнения (CLR). Включение этой опции предоставляет изящную поддержку со стороны Intellisense.

Перейдите в раздел Свойства конфигурации -> NMake и убедитесь, что введенные здесь значения соответствуют необходимым командам make для сборки, очистки и перестроения (часто проекты поставляются с готовым Makefile, и команды в них могут отличаться). Также проверьте имя выходного hex-файла и убедитесь, что пути поиска включаемых файлов соответствуют ожидаемым или добавлены в соответствующие поле ввода. В строке ввода может быть несколько путей поиска, отделенных друг от друга точкой с запятой ‘;’. Если что-то не так, то исправьте.

[Шаг 3. Создание и добавление Makefile]

Создайте файл Makefile для проекта, как Вы это обычно делаете. Лично я предпочитаю использовать готовые Makefile, которые генерирует система AVR Studio, или беру готовый Makefile из разных опубликованных AVR-проектов. Например, множество проектов с отличными Makefile можно найти в составе библиотек V-USB и LUFA [4]. В этом примере я буду использовать готовый Makefile проекта USB HID устройства из библиотеки LUFA-140928.

Сам проект и его makefile находятся в папке DemosDeviceClassDriverGenericHID. Сделайте копию содержимого этой папки в папку Вашего проекта, который Вы только что создали. В моем примере папка проекта находится в каталоге c:TEMPmyAVRproj (у Вас это может быть любой другой каталог на диске).

Файл Makefile обычно должен быть расположен в том же каталоге, где находятся компилируемые файлы исходного кода.

Перед использованием makefile проверьте все его опции, чтобы они соответствовали Вашему компилируемому проекту. Опции makefile редактируются простым текстовым редактором. Здесь я рассмотрю в качестве примера настройку опций для микроконтроллера AT90USB162 и тактовой частоты 16 МГц (макетная плата AVR-USB162).

LUFA_PATH. здесь должен быть указан полный или относительный путь до каталога lufa-LUFA-140928/LUFA. Пример:

LUFA_PATH = c:/asm/lufa-LUFA-140928/LUFA

MCU. Здесь нужно указать тип микроконтроллера. Название микроконтроллера нужно вводить маленькими буквами. Пример:

MCU = at90usb162

BOARD. Здесь указывается символическое название целевого устройства, для которого компилируется проект. Для макетной платы это MICROSIN162:

BOARD = MICROSIN162

F_CPU. Здесь указывается тактовая частота микроконтроллера в Герцах. Она зависит от установленного кварцевого резонатора и коэффициента деления прескалера AVR. Для приложений устройств USB на микроконтроллере AT90USB162 допустимы тактовые частоты ядра 8 или 16 МГц. Пример установки тактовой частоты 16 МГц:

F_CPU = 16000000

После того, как Вы скопировали файл makefile в каталог проекта, добавьте его в каталог Файлы ресурсов проекта Visual Studio. Для этого в Обозревателе решений сделайте правый клик на папке Файлы ресурсов в дереве проекта, и выберите Добавить -> Существующий элемент, и затем в открывшемся диалоге выбора файла выберите файл makefile проекта и кликните на кнопку Добавить.

Как вариант можно просто перетащить в Проводнике файл makefile в папку проекта Файлы ресурсов.

После этого будут работать команды меню Построение -> Очистить решение, Построение -> Построить решение (F7). Однако для удобства редактирования модулей кода их следует добавить в проект.

[Шаг 4. Добавление файлов исходного кода]

Перетащите файлы исходного кода с расширением *.c (для нашего примера Descriptors.c, GenericHID.c) в папку «Файлы исходного кода» Обозревателя решений. Заголовочные файлы с расширением *.h (Descriptors.h, GenericHID.h) перетащите в папку «Заголовочные файлы» Обозревателя решений.

[Шаг 5. Перепрошивка микроконтроллера]

Теперь для полного счастья осталось настроить функцию перепрограммирования микроконтроллера прямо из среды Visual Studio. Для этого через меню Сервис -> Внешние инструменты нужно добавить запуск утилиты для программатора [3]. В этом примере вместо программатора я буду использовать встроенный загрузчик (USB bootloader) Atmel DFU, а в качестве утилиты программирования буду использовать утилиту командной строки Flip DFU (batchisp.exe [5]).

Зайдите в меню Сервис -> Внешние инструменты, нажмите кнопку Добавить.

Для добавленного пункта меню Сервис отредактируйте следующие параметры:

Название: введите Flip DFU (можно ввести произвольное имя).

Команда: введите %ProgramFiles(x86)%AtmelFlip 3.4.7binbatchisp.exe — это полный путь до утилиты batchisp.exe в каталоге установки утилиты Atmel Flip.

Аргументы: введите -device AT90USB162 -hardware usb -operation erase f memory flash blankcheck loadbuffer GenericHID.hex program verify

Исходный каталог: введите $(ProjectDir)

Поставьте галочку «Использовать окно вывода».

После этих действий в меню Сервис появится дополнительный пункт Flip DFU, запускающий программирование памяти контроллера файлом GenericHID.hex через USB-загрузчик. Пример вывода после успешной операции программирования:

Примечание: для программирования плат Arduino, metaboard, AVR-USB-MEGA16 вместо batchisp.exe можно использовать утилиту AVRDUDE, она подойдет не только для работы с загрузчиками, но и с программаторами ISP. Для управления программатором JTAGICE mkII можно использовать утилиту jtagiceii.exe.

[Ссылки]

1. Use Visual Studio IDE to Program AVR/Arduino site:instructables.com .
2. Intel HEX: описание формата файла.
3. Программаторы для AVR.
4. LUFA — бесплатная библиотека USB для микроконтроллеров Atmel AVR.

Источник: microsin.net