Visual studio режим развертывания

Обновлено: 25.06.2024

Создание дистрибутива для Windows приложений это начальный этап процесса развертывания (распространения готового приложения или компонента на другие компьютеры).

В Visual Studio развертывание приложений основано на использовании технологии установщика Microsoft Windows, включающего и средства для создания загружаемых файлов.

Параграф 1. Создание связанного проекта установки

После создания Windows приложения (далее использован проект решения с именем Hello), создадим установочные файлы для его инсталляции на компьютере. Для этого, в контекстном меню проекта (верхний узел в дереве Solutation Explorer), в окне Solution Explorer выбираем пункты Add и New Project (Рис.1.).

Рис.1. Добавление установочного проекта к решению

В левой части мастера Add New Project (Рис.2.), в окне Projeсt Types, выбираем папку Other Project Types\Setup and Deployment, а в правой части - Setup Project. Задаем имя проекта и его размещение (например, HelloSetup - имя не должно совпадать с именем проекта приложения). На данном этапе можно воспользоваться и Setup Wizard (правда, он позволяет сделать далеко не все, что часто требуется). Для большего понимания, пройдем все шаги без использования Setup Wizard.

Рис.2. Добавление установочного проекта к решению

Нажимаем OK. Будет создан установочный (Setup) проект (Рис.3.).

Рис.3. Установочный проект

Среди свойств проекта (Рис.4.): AddRemoveProgramsIcon, Author, Description, DetectNewerInstalledVersion, Keywords, Localization, Manufacturer, ManufacturerUrl, ProductCode, ProductName, RemovePreviousVersions, SearchPath, Subject, SupportPhone, SupportUrl, Title, UpgradeCode, Version. Большинство из них понятны, и могут быть заданы автором программы, исходя из принятых в организации требований. В данном проекте установлено: Manufacturer - Private, ProduktName - HelloSetup, Title - Hello. Свойство AddRemoveProgramsIcon - позволяет установить иконку для описания программы в панели Установка и удаление программ (Пуск\Панель управления\Установка и удаление программ).

Для установки иконки можно выбирать в выпадающем списке AddRemoveProgramsIcon - Browse, затем в окне Icon вновь Browse, в окне Select Item in Project, в его выпадающем списке Look in, выбрать Application Folder. Далее, кнопочкой Add File, вызвав диалог Add File, выбрать любую иконку для Application Folder из имеющихся в файловой системе. Но это можно сделать и по другому, что позволит использовать иконку exe файла приложения (посмотреть установленную иконку приложения или установить новую можно на вкладке Application\Resurses\Icon - контекстное меню приложения - пункт Properties). Как использовать иконку приложения поговорим чуть позже.

Рис.4. Свойства установочного проекта

А пока вернемся к Рис.3. - в левой части окна представлены папки файловой системы компьютера, в одну из которых будет установлено приложение, и, в которые, будет возможно добавить ссылки на папку с установленной программой (пока все папки пусты).

Далее, выделяем папку Application Folder (сюда будет установлен проект). Папки могут быть добавлены при использовании контекстного меню узла File System on Target Machine. Обычно приложения устанавливается в Application Folder. Выбираем пункты Add и Project Output (это же можно сделать и через контекстное меню узла Application Folder).

Рис.5. Добавление приложения Windows в проект установки

Далее, в диалоговом окне Add Object Output Group (Рис.5.) выбираем проект Hello и опцию Primary Output. После нажатия OK в папке Appliсation Folder появится пункт, означающий, что в проект установки добавлены требуемые файлы из проекта Hello (Рис.6.).

PS: На данном этапе в проект можно добавлять папки, файлы и сборки. Например, программа работает с запасом картинок, который должен быть размещен в директории Images. При отладке мы поместим эту директорию с файлами в Debug или Release, но инсталляционная программа ее не подхватит. В этом случае, мы и добавим к установочному проекту директорию Images через пункт Add\Folder, а затем наполним ее файлами - Add\File...

Рис.6. Добавление приложения Windows в проект установки

1. В свойствах узла Users Desktop установить свойство AlwaysCreate в true. Это всегда необходимо, когда shortcut добавляется к специальной папке (Рис.7.).

Рис.7. Создание ярлыка для папки приложения на рабочем столе Windows

Рис.8. Создание ярлыка для папки приложения на рабочем столе Windows

Как результат, в окне Select Item In Project появится ссылка Shortcut to Primary output from Hello (Active).

После нажатия кнопки OK эта ссылка будет перенесена в окно редактора.

Далее можно изменить предложенное длинное имя "Shortcut to Primary output from Hello (Active)" - на то, под которым мы хотим видеть иконку ссылки на папку программы на рабочем столе (например, Hello). Если на данном этапе выполнить Rebuild решения и, далее, установить его, то на рабочем столе появится ссылка на папку, куда будет установлена программа, но у ссылки пока не будет иконки (вернее, будет стандартная иконка).

Создадим иконки для ссылок на рабочем столе, в меню Пуск\Программы, а также, для записи об установленной программе в окне Пуск\Панель управления\Установка и удаление программ (стандартная запись в окне Установка и удаление программ - один из результатов работы программы установки).

Добавление иконок для всех перечисленных случаев, во многом аналогично по последовательности действий. Отличие заключается лишь в том, что для записи о программе в окне Установка и удаление программ, перечисленные ниже действия выполняются для узла проекта установки и свойства AddRemoveProgramsIcon, а для остальных папок, для свойств Icon имен ссылок (у нас, имен ссылок Users Desktop и Users Programm Menu - Hello). Добавление иконок показано на Рис.9. и Рис.10.

Для установки иконки, в выпадающем списке соответственно перечисленных выше свойств, выбираем - Browse (Рис.9.), затем в окне Icon вновь Browse, в окне Select Item in Project, в его выпадающем списке Look in, выбираем Application Folder. Установив Files of Type в All Files выбираем Primary Output From Hello (Active), нажимаем OK. Иконка будет извлечена из ресурса приложения (Рис.10., справа) и, по нажатию кнопки OK, добавлена как иконка для записи или папки.

Для добавления иконки в другие папки, от момента выбора в выпадающем списке пункта Browse, как для рабочего стола, так и для Пуск\Программы в свойстве Icon (а не AddRemoveProgramsIcon для записи в Установка и удаление программ), все повторяется без единого отклонения.

Рис.9. Создание иконок для папок и записи в окне Установка и удаление программ

Рис.10. Создание иконок для папок и записи в окне Установка и удаление программ

В окне Select Item In Project, после выбора Application Folder можно также использоать и любой файл .ico, нажав кнопку Add File, как мы об этом говорили выше.

Вновь перекомпилируем проект (в контекстом меню Solution Explorer узла HelloSetup пункт Rebuild Solutation). В папке Release для HelloSetup будут созданы файлы setup.exe, hellosetup.msi. Это инсталляционные файлы приложения.

После запуска файла setup.exe будет выполнена установка приложения - для приложения появится отдельная запись в Пуск\Панель управления\Установка и удаление программ, а ссылка на папку приложения, в виде выбранной иконки - на рабочем столе и в меню Пуск\Программы.

Параграф 2. Создание разделенного с проектом решения проекта установки

Обратим внимание на то, что предыдущий способ установки приложения не позволяет создать ссылку на непосредственно exe файл - его пока нет - он будет создан при компиляции. И, хотя это, не столь важно, ссылки на рабочий стол могут вытащить и школьники, но другой недостаток предыдущего способа - хранить два проекта вместе - во многом говорит о необходимости отдать предпочтение способу, описанному ниже.

Создадим новый проект, как показано на Рис.11. и Рис.12.

Рис.11. Создание установочного проекта

Рис.12. Создание установочного проекта

Свойства проекта, созданные папки мы рассматривали выше, поэтому не будем аовторять изложенное выше. Установим режим компиляции проекта Release. В этом режиме в папке bin\Release, будет сформирован exe файл, перенесены необходимые библиотеки при их использовании и исключена отладочная информация. Исходный проект (Hello) также должен быть скомпилирован в режиме Release.

Свойства самого проекта пока нового ничего нам не дают (Рис.13.).

Рис.13. Свойства установочного проекта

Рис.14. Добавление исполняемого файла в проект установки

Аналогично перенесем все файлы из директории \bin\Release\ в папку (если он там не один).

После этого можно приступить к созданию ссылок и иконок.

Иконка для установочной записи в Установка и удаление программ выбирается точно также, как описано выше (свойство AddRemoveProgramsIcon, в качестве ресурса в Application Folder в окне Select Item In Project выбираем Hello.exe файл Рис.9. и Рис.10.).

Добавление ссылок на рабочий стол и в меню Пуск\Программы немного отличается от предыдущего способа. В контекстном меню файла Hello.Exe дважды выбираем пункт Create Shortcut to Hello.Exe. В окне Name появятся два имени ссылок. Сразу в окне Properties для ссылок переименуем их имена на те, с которыми мы хотим их видеть на рабочем столе и в меню Пуск\Программы. Ссылки созданы, осталось перетащить эти ссылки на соответствующие папки (Рис.15., Рис.16.).

Рис.15. Добавление ссылок на рабочий стол и в меню Пуск\Программы

Рис.16. Добавление ссылок на рабочий стол и в меню Пуск\Программы

Осталось повторить, то, что мы делали. Установить свойства папок AlwaysCreate в true, и снабдить ссылки иконками.

В разделах ниже содержатся сведения об использовании Microsoft Visual Studio для создания следующих типов развертывания:

развертывание, зависящее от платформы;
развертывание, зависящее от платформы, с зависимостями сторонних разработчиков;
автономное развертывание;
Автономное развертывание с зависимостями сторонних разработчиков

развертывание, зависящее от платформы;

Добавление исходного кода приложения.

Откройте файл Program.cs или Program.vb в редакторе и замените автоматически созданный код приведенным ниже кодом. Он выводит запрос на ввод текста и отображает отдельные слова, введенные пользователем. Для разделения слов во введенном тексте в нем используется регулярное выражение \w+ .

Создание отладочной сборки приложения.

Выберите Сборка > Собрать решение. Также можно скомпилировать и выполнить отладочную сборку приложения, выбрав Отладка > Начать отладку.

Отладив и протестировав программу, создайте файлы, которые будут развертываться с приложением. Для публикации из Visual Studio выполните следующие действия.

На панели инструментов измените конфигурацию решения с Отладка на Выпуск, чтобы собрать версию выпуска (а не отладочную версию) приложения.

Щелкните правой кнопкой мыши проект (не решение) в обозревателе решений и выберите Опубликовать.

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

Теперь на вкладке Публикация отображается один профиль — FolderProfile. Параметры конфигурации профиля отображаются на вкладке в разделе Сводка.

Итоговые файлы помещаются в каталог с именем Publish в Windows и publish в системах Unix, который находится в подкаталоге каталога проекта .\bin\release\netcoreapp2.1.

Помимо файлов приложения, процесс публикации создает файл базы данных программы (PDB), который содержит отладочную информацию о приложении. Файл используется в основном для отладки исключений. Его можно не упаковывать вместе с файлами приложения. Однако его следует сохранить на случай, если потребуется выполнить отладку сборки выпуска приложения.

Любым способом разверните полный набор файлов приложения. Например, их можно упаковать в ZIP-файл, использовать простую команду copy или развернуть их с помощью любого установочного пакета на ваш выбор. После установки пользователи могут выполнять приложение с помощью команды dotnet , указав имя файла приложения, например dotnet fdd.dll .

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

Развертывание, зависящее от платформы, с зависимостями сторонних разработчиков

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

С помощью диспетчера пакетов NuGet добавьте ссылку на пакет NuGet в проект, а если пакет еще недоступен в системе, установите его. Чтобы открыть диспетчер пакетов, последовательно выберите Сервис > Диспетчер пакетов NuGet > Управление пакетами NuGet для решения.

Убедитесь, что в вашей системе установлены зависимости от сторонних разработчиков (например, Newtonsoft.Json ), если это не так, установите их. На вкладке Установленные перечислены пакеты NuGet, установленные в системе. Если Newtonsoft.Json отсутствует в списке, откройте вкладку Обзор и введите "Newtonsoft.Json" в поле поиска. Выберите Newtonsoft.Json и в области справа выберите проект, прежде чем нажать кнопку Установить.

Если Newtonsoft.Json уже установлен в системе, добавьте его в проект, выбрав проект в правой области на вкладке Управление пакетами для решения.

Переносимость зависящего от платформы развертывания с зависимостями сторонних разработчиков напрямую зависит от переносимости этих зависимостей. Например, если библиотека стороннего разработчика поддерживает только Mac OS, приложение нельзя перенести в системы Windows. Это происходит, если зависимость стороннего разработчика сама зависит от машинного кода. Хорошим примером является сервер Kestrel, требующий собственной зависимости от libuv. Когда зависящее от платформы развертывание создается для приложения с таким типом зависимости стороннего разработчика, опубликованные выходные данные содержат папку для каждого идентификатора среды выполнения (RID), поддерживаемого зависимостью (и имеющегося в ее пакете NuGet).

Автономное развертывание без зависимостей сторонних разработчиков

Добавление исходного кода приложения.

Определите, хотите ли вы использовать инвариантный режим глобализации.

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

Чтобы включить инвариантный режим, щелкните правой кнопкой мыши проект (не решение) в обозревателе решений и выберите Изменить SCD.csproj или Изменить SCD.vbproj. Затем добавьте следующие выделенные строки в файл:

Создание отладочной сборки приложения.

Выберите Сборка > Собрать решение. Также можно скомпилировать и выполнить отладочную сборку приложения, выбрав Отладка > Начать отладку. Этот шаг отладки позволяет выявить проблемы в приложении, когда оно выполняется на вашей платформе. Его все равно придется тестировать на каждой целевой платформе.

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

Когда вы закончите отладку, вы можете опубликовать автономное развертывание.

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

Для публикации приложения из Visual Studio выполните следующие действия.

Определение платформ, для которых будет предназначено приложение.

Щелкните правой кнопкой мыши проект (не решение) в обозревателе решений и выберите Изменить SCD.csproj.

В разделе <PropertyGroup> файла csproj создайте тег <RuntimeIdentifiers> , определяющий платформы, для которых предназначено приложение, и укажите идентификатор среды выполнения (RID) каждой целевой платформы. Для разделения идентификаторов RID необходимо добавлять точку с запятой. Список идентификаторов сред выполнения см. в каталоге идентификаторов сред выполнения.

Например, приведенный ниже пример указывает, что приложение выполняется в 64-разрядной операционной системе Windows 10 и в 64-разрядной операционной системе OS X 10.11.

Элемент <RuntimeIdentifiers> можно переносить в другие группы <PropertyGroup> в пределах файла csproj. Полный пример файла csproj будет приведен далее в этом разделе.

Для публикации приложения из Visual Studio выполните следующие действия.

Щелкните правой кнопкой мыши проект (не решение) в обозревателе решений и выберите Опубликовать.

Теперь на вкладке Публикация отображается один профиль — FolderProfile. Параметры конфигурации профиля отображаются на вкладке в разделе Сводка. Параметр Целевая среда выполнения определяет, какая среда выполнения была опубликована, а параметр Целевое расположение определяет, куда были записаны файлы автономного развертывания.

По умолчанию Visual Studio записывает все опубликованные файлы в один каталог. Для удобства рекомендуется создать отдельные профили для каждой целевой среды выполнения и размещать опубликованные файлы в каталоге для определенной платформы. Это предполагает создание отдельного профиля публикации для каждой целевой платформы. Теперь выполните повторную сборку приложения для каждой платформы следующим образом.

Выберите Создать новый профиль в диалоговом окне Публикация.

В списке профилей выберите новый профиль (FolderProfile1) и убедитесь, что параметр Целевая среда выполнения имеет значение win10-x64 . В противном случае выберите Параметры. В диалоговом окне Параметры профиля измените значение параметра Целевая среда выполнения на win10-x64 , а затем нажмите кнопку Сохранить. В противном случае нажмите кнопку Отмена.

Выберите Опубликовать, чтобы опубликовать приложение для 64-разрядных платформ Windows 10.

Выполните приведенные выше шаги еще раз, чтобы создать профиль для платформы osx.10.11-x64 . Параметр Целевое расположение имеет значение bin\Release\PublishOutput\osx.10.11-x64, а параметр Целевая среда выполнения — osx.10.11-x64 . Visual Studio присваивает этому профилю имя FolderProfile2.

Разверните опубликованные файлы любым способом. Например, их можно упаковать в ZIP-файл, использовать простую команду copy или развернуть их с помощью любого установочного пакета на ваш выбор.

Ниже приведено полное содержимое файла csproj для этого проекта.

Создание после отладки и тестирования программы файлов, которые будут развертываться с приложением, для каждой целевой платформы. Это предполагает создание отдельного профиля для каждой целевой платформы.

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

Создайте профиль для целевой платформы.

Если это первый созданный профиль, щелкните правой кнопкой мыши проект (не решение) в обозревателе решений и выберите Опубликовать.

Если вы уже создали профиль, щелкните правой кнопкой мыши проект, чтобы открыть диалоговое окно Опубликовать, если оно еще не открыто. Затем выберите Создать профиль.

Откроется диалоговое окно Выбрать целевой объект для публикации.

Выберите расположение, где Visual Studio опубликует приложение.

Если вы публикуете приложение только на одной платформе, можно принять значение по умолчанию в текстовом поле Выбрать папку. Вы опубликуете зависимое от платформы развертывание приложения в каталоге <project-directory>\bin\Release\netcoreapp2.1\publish.

Если публикация выполняется для нескольких платформ, добавьте строку, которая указывает целевую платформу. Например, если добавить строку "linux" в путь к файлу, Visual Studio опубликует развертывание приложения, зависимое от платформы, в каталоге <project-directory>\bin\Release\netcoreapp2.1\publish\linux.

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

Укажите, что вы публикуете автономное развертывание, и определите платформу, для которой будет предназначено приложение.

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

Выберите Автономное в списке Режим развертывания.

В списке Целевая среда выполнения выберите одну из платформ, для которой предназначено приложение.

Нажмите Сохранить, чтобы принять изменения и закрыть диалоговое окно.

Укажите имя профиля.

Выберите Действия > Переименовать профиль, чтобы указать имя профиля.

Выберите для профиля имя, которое указывает на целевую платформу, а затем нажмите *Сохранить.

Повторите эти шаги, чтобы определить любые дополнительные целевые платформы, для которых предназначено приложение.

Вы настроили профили и готовы опубликовать приложение. Выполните указанные ниже действия.

Если диалоговое окно Опубликовать еще не открыто, щелкните правой кнопкой мыши проект (не решение) в обозревателе решений и выберите Опубликовать.

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

Ниже приведено полное содержимое файла csproj для этого проекта.

Кроме того, Visual Studio создает отдельный профиль публикации (*.pubxml) для каждой целевой платформы. Например, файл для профиля linux (linux.pubxml) выглядит следующим образом:

Автономное развертывание с зависимостями сторонних разработчиков

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

Ниже приведено полное содержимое файла csproj для этого проекта:

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

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

Справочные сведения о задаче развертывания:

Не знаете, какой вариант развертывания выбрать? Ознакомьтесь со статьей Выбор подходящих вариантов публикации.

Сведения об устранении проблем с развертыванием Службы приложений Azure или служб IIS см. в этой статье.

Чтобы выполнить развертывание в новый целевой объект, если вы ранее создали профиль публикации, для настроенного профиля в окне Публикация выберите Создать.

Затем выберите вариант развертывания в средстве публикации. Сведения о вариантах публикации см. в следующих разделах.

Выбор подходящих вариантов публикации

Из среды Visual Studio приложения можно публиковать напрямую в следующие целевые объекты:

Как показано на следующем рисунке, при создании профиля публикации появятся перечисленные выше варианты.

Краткий обзор общих вариантов развертывания приложений см. в статье Первое знакомство с развертыванием.

Azure

В Azure можно выбрать один из следующих вариантов:

Служба приложений Azure

Вычислительная мощность службы приложений определяется выбором ценовой категории или плана для размещающей службы приложений. Несколько веб-приложений (или приложений другого типа) могут совместно использовать одну и ту же службу приложений без изменения ценовой категории. Например, веб-приложения для разработки, промежуточного этапа и рабочей среды можно разместить в одной службе приложений.

Когда следует использовать службу приложений Azure

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

Если вы хотите использовать службу приложений Azure в своем центре обработки данных или на других локальных компьютерах, воспользуйтесь для этого Azure Stack.

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

Реестр контейнеров Azure

Реестр контейнеров Azure позволяет создавать, хранить, а также администрировать образы и артефакты контейнеров Docker в частном реестре для всех типов развертываний контейнеров.

В каких случаях нужно выбрать Реестр контейнеров Azure

Если у вас уже есть конвейер разработки и развертывания для контейнера Docker.
Если вы хотите создать образы контейнеров Docker в Azure.

Виртуальная машина Azure

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

Масштабирование приложения, размещенного на виртуальных машинах, предполагает запуск дополнительных виртуальных машин по требованию и последующее развертывание необходимого программного обеспечения. Этот дополнительный уровень управления позволяет вам применять разные режимы масштабирования в разных глобальных регионах. Например, если ваше приложение обслуживает сотрудников в различных региональных офисах, вы можете масштабировать ваши виртуальные машины в зависимости от количества сотрудников в этих регионах, что способствует сокращению затрат.

Дополнительные сведения см. в статье с подробным сравнением Службы приложений Azure, Виртуальных машин Azure и других служб Azure, которые можно использовать в качестве целевого объекта развертывания, применив параметр "Пользовательский" в Visual Studio.

В каких случаях нужно выбрать виртуальные машины Azure

Вы хотите развернуть веб-приложение, доступное через Интернет, с полным контролем над временем существования назначенных IP-адресов.
Вам требуются настройки уровня компьютера на серверах, к которым относится установка дополнительного программного обеспечения, такого как специальная система базы данных, определенные сетевые конфигурации, разделы диска и т. д.
Вам требуется точный контроль над масштабированием веб-приложения.
Вам по любой причине необходим прямой доступ к серверам, на которых размещается приложение.

Если вы хотите использовать виртуальные машины Azure в своем центре обработки данных или на других локальных компьютерах, воспользуйтесь для этого Azure Stack.

Реестр контейнеров Docker

Если в вашем контейнерном приложении используется Docker, вы можете опубликовать его в реестре контейнеров Docker.

В каких случаях следует выбирать реестр контейнеров Docker

Вам требуется развернуть контейнерное приложение

Дополнительные сведения см. в следующих разделах:

Папка

Развертывание в файловой системе означает копирование файлов приложения в определенную папку на локальном компьютере. Этот подход чаще всего используется при тестировании или развертывании приложения для использования ограниченным количеством пользователей, если компьютер также работает как сервер. Если целевая папка является общей для сети, при развертывании в файловой системе файлы веб-приложения станут доступны другим пользователям, которые затем смогут развернуть их на конкретных серверах.

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

Если по какой-либо причине (например, из-за особенностей доступа к компьютеру) вы не можете использовать облачные службы, например Службу приложений Azure или Виртуальные машины Azure, можно использовать Azure Stack в центре обработки данных. Azure Stack позволяет использовать вычислительные ресурсы и управлять ими с помощью службы приложений Azure и виртуальных машин Azure, поддерживая все активы в локальной среде.

Когда следует использовать развертывание файловой системы

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

Вам необходимо только локальное тестовое развертывание.
Вы хотите проверять и при необходимости изменять файлы приложения независимо друг от друга перед их отправкой в другой целевой объект развертывания.

Дополнительные сведения о выборе параметров см. в следующих статьях:

Сервер FTP или FTPS

Вариант "Сервер FTP или FTPS" позволяет развернуть приложение на сервере вне платформы Azure. Его можно развернуть в файловой системе или на любом другом сервере (в Интернете или интрасети), к которому у вас есть доступ, включая области в других облачных службах. Он может работать с веб-развертыванием (файлы или ZIP) и FTP.

Если вы выберете вариант "Сервер FTP или FTPS", Visual Studio запросит имя профиля и дополнительные сведения о подключении, включая данные о целевом сервере или расположении, имя сайта и учетные данные. Вы можете выбрать следующие варианты поведения на вкладке Параметры.

Конфигурации, которые нужно развернуть.
Нужно ли удалить существующие файлы из назначения.
Использовать ли предварительную компиляцию во время публикации.
Следует ли исключать из развертывания файлы, размещенные в папке App_Data.

В Visual Studio вы можете создать любое количество профилей развертывания для FTP или FTPS, что позволяет использовать несколько профилей с разными параметрами.

В каких случаях нужно выбрать развертывание на сервере FTP или FTPS

Вы используете облачные службы на платформе, отличной от Azure, доступ к которой возможен через URL-адреса.
Вы хотите использовать для развертывания учетные данные, отличные от используемых в Visual Studio, или напрямую связанные с вашими учетными записями Azure.
Вы хотите удалять файлы из целевого объекта при каждом развертывании.

Веб-сервер (IIS)

Вариант "Веб-сервер (IIS)" позволяет развернуть приложение на веб-сервере вне платформы Azure. Поддерживается развертывание на любом сервере IIS (в Интернете или интрасети), к которому у вас есть доступ, в том числе в других облачных службах. Этот вариант совместим с расширением или пакетом веб-развертывания.

Если вы выберете вариант "Веб-сервер (IIS)", Visual Studio запросит имя профиля и дополнительные сведения о подключении, включая данные о целевом сервере или расположении, имя сайта и учетные данные. Вы можете выбрать следующие варианты поведения на вкладке Параметры.

Конфигурации, которые нужно развернуть.
Нужно ли удалить существующие файлы из назначения.
Использовать ли предварительную компиляцию во время публикации.
Следует ли исключать из развертывания файлы, размещенные в папке App_Data.

В Visual Studio вы можете создать любое количество профилей развертывания для веб-сервера IIS, что позволяет использовать несколько профилей с разными параметрами.

В каких случаях нужно выбрать развертывание на веб-сервере IIS

Если вы уже используете IIS для публикации сайта или службы, доступ к которым осуществляется по URL-адресам.
Вы хотите использовать для развертывания учетные данные, отличные от используемых в Visual Studio, или напрямую связанные с вашими учетными записями Azure.
Вы хотите удалять файлы из целевого объекта при каждом развертывании.

Профиль импорта

Вы можете импортировать профиль при публикации в службу IIS или Службу приложений Azure. Развертывание можно настроить с помощью файла параметров публикации ( *.publishsettings). Файл параметров публикации создается IIS или Службой приложений Azure либо может быть создан вручную, после чего его можно импортировать в Visual Studio.

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

Развертывание приложения, службы или компонента — это механизм их распространения для установки на других компьютерах, устройствах, серверах и в облаке. В Visual Studio можно выбрать соответствующий подход в зависимости от требуемого типа развертывания. (Многие приложения различных типов поддерживают другие средства развертывания, такие как развертывание из командной строки или NuGet, которые не описываются в этой статье.)

Пошаговые инструкции по развертыванию см. в кратких руководствах и учебниках. Обзор вариантов развертывания см. в статье Выбор подходящих вариантов публикации.

Развертывание в локальную папку

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

Классические приложения Windows. Вы можете публиковать классические приложения Windows в папке, используя развертывание ClickOnce. Затем пользователи смогут устанавливать приложение одним щелчком. Дополнительные сведения см. в следующих статьях:

Публикация в Azure

Чтобы иметь больше возможностей для настройки конфигурации сервера, также можно использовать средство публикации для развертывания приложений на виртуальной машине Azure.

Чтобы использовать средство публикации, щелкните правой кнопкой мыши проект в обозревателе решений и выберите Опубликовать. (Если профили публикации не были настроены ранее, необходимо щелкнуть Создать профиль.) В диалоговом окне Публикация выберите Служба приложений или Виртуальные машины Azure и выполните инструкции по настройке.

Информацию о приложениях Python см. в статье Python. Публикация в службу приложений Azure.

Если у вас нет учетной записи Azure, вы можете зарегистрироваться здесь.

Публикация в Интернете или развертывание в сетевой папке

В Обозревателе решений щелкните проект правой кнопкой мыши и выберите Опубликовать. (Если профили публикации не были настроены ранее, необходимо щелкнуть Создать профиль.) В средстве публикации выберите нужный вариант и выполните инструкции по настройке.

Дополнительные сведения об импорте профиля публикации в Visual Studio см. в статье Импорт параметров публикации и развертывание в IIS.

Классические приложения Windows. Вы можете публиковать классическое приложение Windows на веб-сервере или в общей сетевой папке, используя развертывание ClickOnce. Затем пользователи смогут устанавливать приложение одним щелчком. Дополнительные сведения см. в следующих статьях:

Создание пакета установщика (классическое приложение Windows)

Если возможностей ClickOnce недостаточно для установки вашего классического приложения, вы можете создать пакет установщика Windows (файл установки MSI или EXE) или собственный начальный загрузчик.

Пакет установщика на базе MSI можно создать с помощью расширения с набором инструментов WiX для Visual Studio 2017. Это программа командной строки.

Пакет установщика MSI или EXE можно создать, используя InstallShield от Flexera Software. Вместе с Visual Studio 2017 и последующими версиями можно использовать компонент InstallShield. Выпуск Community Edition не поддерживается.

Версия InstallShield Limited Edition больше не входит в состав Visual Studio и не поддерживается в Visual Studio 2017 и последующих версиях. Информацию о ее дальнейшей доступности см. в документации Flexera Software.

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

Публикация в Microsoft Store

В среде Visual Studio можно создавать пакеты приложений для развертывания в Microsoft Store.

Универсальная платформа Windows. Вы можете упаковать свое приложение и развернуть его, используя пункты меню. Дополнительные сведения см. в статье Упаковка приложения UWP с помощью Visual Studio.

Классические приложения Windows. Начиная с версии Visual Studio 2017 15.4, вы можете выполнять развертывание в Microsoft Store, используя мост для классических приложений. Для этого сначала необходимо создать проект упаковки приложений Windows. Дополнительные сведения см. в статье Упаковка классического приложения для Microsoft Store (мост для классических приложений).

Развертывание на устройство (универсальная платформа Windows)

Если вы развертываете приложение универсальной платформы Windows на устройство в целях тестирования, ознакомьтесь со статьей Запуск приложений UWP на удаленном компьютере в среде Visual Studio.

Развертывание в тестовой лаборатории

Чтобы иметь возможности для реализации более сложных сценариев разработки и тестирования, можно развертывать приложения в виртуальных средах. Дополнительные сведения см. в статье Тестирование в лабораторной среде.

Непрерывное развертывание

Для непрерывного развертывания приложения можно использовать Azure Pipelines. Дополнительные сведения см. в статьях Azure Pipelines и Развертывание в Azure.

Как настроить такую публикацию на примере консольного приложения?

На самом деле процесс настройки такой публикации ничем не отличается от того, что мы привыкли видеть в соответствующем мастере Visual Studio проходя все его окна. Отличие появляется только в самом конце настройки, так как для публикации в режиме «автономного исполняемого файла» требуется изменить значения от одного до трёх параметров (в зависимости от того, что вы хотите получить в итоге) заданные по умолчанию.

В случае необходимости эти параметры можно изменить в уже готовом профиле публикации. В частности, при публикации в папку изменить данные параметры в мастере на этапе его первоначальной настройки невозможно.

Для этого выберите профиль и нажмите ссылку «Показать все параметры».

В появившемся окне установите для параметра «Режим развёртывания» значение «Автономное».

По умолчанию параметр «Целевая среда выполнения» имеет значение «win-x86». Если вы планируете публиковать приложение для другой платформы вам нужно указать соответствующую платформу, как показано на скриншоте ниже.

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

Для того чтобы сохранить внесённые изменения нажмите кнопку «Сохранить».

После публикации приложения мы увидим в соответствующей папке все необходимые файлы.

Для простейшего консольного приложения (стандартный шаблон Visual Studio с «Hello, world!» получилось в общей сложности 225 файлов с общим размером порядка 58 МБ.

Многовато для «Hello, world!», но такова плата за автономность.

В прочем существует способ сократить количество и, правда в незначительной степени, размер выходных файлов. Для этого нужно включить опцию «Создать отдельный файл», как показано ниже.

В этом случае создаётся всего 6 файлов с общим размером чуть больше 52 МБ.

При этом основная часть приходится на исполняемый файл приложения (в нашем примере это ConsoleApp1.exe)

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

Если вы используете для публикации приложений ClickOnce, то настройка несколько упрощается так как в этом случае мастер позволяет задать нужные настройки ещё на этапе создания профиля публикации.

В случае же, например, десктопных приложений или standalone сервисов такой подход может оказаться вполне оправданным.

Читайте также: