Учебник. Публикация консольного приложения .NET с помощью Visual Studio Tutorial: Publish a .NET console application using Visual Studio

В этом руководстве показано, как опубликовать консольное приложение, чтобы его могли запускать другие пользователи. This tutorial shows how to publish a console app so that other users can run it. При публикации создается набор файлов, которые необходимы для запуска приложения. Publishing creates the set of files that are needed to run your application. Чтобы развернуть файлы, скопируйте их на целевой компьютер. To deploy the files, copy them to the target machine.

Предварительные требования Prerequisites

• В этом руководстве используется консольное приложение, созданное в руководстве Создание консольного приложения .NET в Visual Studio. This tutorial works with the console app that you create in Create a .NET console application using Visual Studio.

Публикация приложения Publish the app

Запустите Visual Studio. Start Visual Studio.

Откройте проект HelloWorld, созданный по инструкциям из статьи Создание консольного приложения .NET в Visual Studio. Open the HelloWorld project that you created in Create a .NET console application using Visual Studio.

Убедитесь, что в Visual Studio используется конфигурация сборки Release. Make sure that Visual Studio is using the Release build configuration. При необходимости измените конфигурацию сборки на панели инструментов, указав конфигурацию Выпуск вместо конфигурации Отладка. If necessary, change the build configuration setting on the toolbar from Debug to Release.

Щелкните проект HelloWorld (не решение HelloWorld) правой кнопкой мыши и выберите Опубликовать. Right-click on the HelloWorld project (not the HelloWorld solution) and select Publish from the menu.

На вкладке Целевой объект на странице Публикация выберите Папка, а затем нажмите кнопку Далее. On the Target tab of the Publish page, select Folder, and then select Next.

На вкладке Определенный целевой объект на странице Публикация выберите Папка, а затем нажмите кнопку Далее. On the Specific Target tab of the Publish page, select Folder, and then select Next.

На вкладке Расположение на странице Публикация нажмите кнопку Готово. On the Location tab of the Publish page, select Finish.

На вкладке Публикация в окне Публикация нажмите кнопку Опубликовать. On the Publish tab of the Publish window, select Publish.

Проверка файлов Inspect the files

По умолчанию при публикации создается развертывание, зависящее от платформы. При таком развертывании опубликованное приложение выполняется на компьютере с установленной средой выполнения .NET. By default, the publishing process creates a framework-dependent deployment, which is a type of deployment where the published application runs on machine that has the .NET runtime installed. Пользователи могут запустить опубликованное приложение, дважды щелкнув исполняемый файл или выполнив команду dotnet HelloWorld.dll из командной строки. Users can run the published app by double-clicking the executable or issuing the dotnet HelloWorld.dll command from a command prompt.

В следующих шагах будут рассмотрены файлы, созданные в процессе публикации. In the following steps, you’ll look at the files created by the publish process.

В обозревателе решений выберите Показать все файлы. In Solution Explorer, select Show all files.

В папке проекта разверните узел bin/Release/net5.0/publish. In the project folder, expand bin/Release/net5.0/publish.

Как показано на рисунке, опубликованные выходные данные включают следующие файлы: As the image shows, the published output includes the following files:

Это файл зависимостей среды выполнения приложения. This is the application’s runtime dependencies file. Он определяет библиотеки и компоненты .NET (включая библиотеку DLL, содержащую приложение), необходимые для запуска приложения. It defines the .NET components and the libraries (including the dynamic link library that contains your application) needed to run the app. Дополнительные сведения см. в разделе Runtime Configuration Files (Файлы конфигурации среды выполнения). For more information, see Runtime configuration files.

Это версия зависимого от платформы развертывания приложения. This is the framework-dependent deployment version of the application. Чтобы выполнить эту библиотеку динамической компоновки, введите dotnet HelloWorld.dll в командной строке. To execute this dynamic link library, enter dotnet HelloWorld.dll at a command prompt. Этот метод запуска приложения работает на любой платформе, где установлена среда выполнения .NET. This method of running the app works on any platform that has the .NET runtime installed.

Это версия исполняемого, зависящего от платформы файла приложения. This is the framework-dependent executable version of the application. Чтобы запустить его, введите HelloWorld.exe в командной строке. To run it, enter HelloWorld.exe at a command prompt. Файл зависит от операционной системы. The file is operating-system-specific.

HelloWorld.pdb (необязателен для развертывания) HelloWorld.pdb (optional for deployment)

Это файл отладочных символов. This is the debug symbols file. Этот файл не нужно распространять вместе с приложением, но желательно сохранить его на случай, если придется выполнять отладку опубликованной версии приложения. You aren’t required to deploy this file along with your application, although you should save it in the event that you need to debug the published version of your application.

Это файл конфигурации среды выполнения для приложения. This is the application’s run-time configuration file. Он определяет версию платформы .NET, для которой предназначено приложение. It identifies the version of .NET that your application was built to run on. Кроме того, в него можно добавить параметры конфигурации. You can also add configuration options to it. Дополнительные сведения см. в статье Параметры конфигурации среды выполнения .NET. For more information, see .NET run-time configuration settings.

Запуск опубликованного приложения Run the published app

В обозревателе решений щелкните папку publish правой кнопкой мыши и выберите команду Копировать полный путь. In Solution Explorer, right-click the publish folder, and select Copy Full Path.

Откройте командную строку и перейдите к папке publish. Open a command prompt and navigate to the publish folder. Для этого введите cd и вставьте полный путь. To do that, enter cd and then paste the full path. Пример: For example:

Запустите приложение с помощью исполняемого файла: Run the app by using the executable:

Введите HelloWorld.exe и нажмите клавишу ВВОД . Enter HelloWorld.exe and press Enter .

В ответ на запрос введите имя и нажмите любую клавишу, чтобы выйти. Enter a name in response to the prompt, and press any key to exit.

Запустите приложение с помощью команды dotnet : Run the app by using the dotnet command:

Введите dotnet HelloWorld.dll и нажмите клавишу ВВОД . Enter dotnet HelloWorld.dll and press Enter .

В ответ на запрос введите имя и нажмите любую клавишу, чтобы выйти. Enter a name in response to the prompt, and press any key to exit.

Дополнительные ресурсы Additional resources

Следующие шаги Next steps

В этом руководстве вы опубликовали консольное приложение. In this tutorial, you published a console app. Далее вы создадите библиотеку классов. In the next tutorial, you create a class library.

Особенности публикации приложений в Windows

Службы терминалов Windows позволяют осуществить полноценную публикацию приложений

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

Имеется ряд обстоятельств, при которых публикация приложений предпочтительна. Так, неподготовленным пользователям работать с опубликованным приложением проще, чем с удаленным рабочим столом. Отсутствие в пользовательских терминальных сессиях рабочего стола с его многочисленными элементами управления повышает безопасность решений на базе служб терминалов. Более экономно расходуются серверные ресурсы, главным образом оперативная память. И наконец, опубликованные приложения удобно размещать на Web-страницах с доступом к ним из браузера Internet Explorer посредством клиентских компонентов ActiveX службы терминалов.

Службы терминалов Windows и Citrix Metaframe

Службы терминалов Windows, работающие по протоколу RDP (Remote Desktop Protocol), пока уступают по своим возможностям продукту Citrix Metaframe, в основе которого лежит протокол ICA (Independent Computing Architecture). Например, Metaframe поддерживает режим эмуляции локальных окон (seamless windows), а службы терминалов Windows — нет. В случае RDP-соединения приложение всегда запускается в окне терминальной сессии. Размер окна приложения можно изменить, можно развернуть окно приложения на все окно терминальной сессии, но размер окна терминальной сессии остается постоянным. Если в процессе работы будут открыты новые окна приложений, то они также будут находиться в пределах окна терминальной сессии (см. экран 1).

Экран 1. Несколько окон приложений в одном окне терминальной сессии

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

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

Настройки служб терминалов Windows

Для того чтобы опубликовать приложение с помощью служб терминалов Windows (в дальнейшем — «службы терминалов»), обычно достаточно выполнить следующие настройки: указать полный путь к исполняемому файлу приложения, которое будет запущено вместо удаленного рабочего стола, а также данные учетной записи для автоматической аутентификации. Необходимые настройки могут быть выполнены как на стороне клиента службы терминалов, так и на сервере в консоли Terminal Services Configuration. Также можно изменить параметры учетной записи пользователя, относящиеся к терминальным подключениям.

Экран 2. Дополнительные объекты Connection в окне Terminal Services Configuration

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

К сожалению, здесь возникает новая проблема. Дело в том, что параметры терминальных сессий определяются на сервере в свойствах объекта Connection, доступного в консоли Terminal Services Configuration. Поскольку каждому сетевому интерфейсу можно сопоставить не более одного объекта Connection, это означает, что на терминальном сервере можно опубликовать столько приложений, сколько сетевых адаптеров установлено физически. Помимо этого, для каждого сетевого адаптера потребуется выделить IP-адрес, выполнить его подключение к сетевому оборудованию и т. д. Даже если на терминальном сервере с одним сетевым адаптером опубликовано единственное приложение, становится невозможным использование терминальных служб для других задач, например для удаленного администрирования. Можно ли добавлять объекты Connection как-нибудь иначе, не устанавливая в терминальный сервер новых устройств?

Несуществующие сетевые интерфейсы и служба RRAS

Оказывается, можно, но потребуется применить довольно нестандартную настройку сетевой конфигурации и службы RRAS (Routing and Remote Access Service). Сначала добавим в систему фиктивные «сетевые адаптеры» типа Microsoft Loopback Adapter. Это позволит создать в конфигурации службы терминалов новые объекты Connection и привязать каждый из них к своему «сетевому адаптеру». Затем мы воспользуемся возможностями службы RRAS для маршрутизации обращений из локальной сети к фиктивным «сетевым адаптерам». Рассмотрим данный способ более подробно.

Экран 3. Правила перенаправления IP-пакетов в протоколе NAT

Используя мастер установки оборудования, следует добавить в систему одно или несколько «устройств» типа Microsoft Loopback Adapter (по числу приложений, планируемых для публикации). В процессе установки необходимо указать, что устройство будет выбрано вручную, далее в списке классов устройств нужно выбрать Network Adapters, а в списке производителей — Microsoft. Для установки следующего «устройства» процедуру требуется повторить. По окончании установки обязательна перезагрузка сервера, хотя прямого указания на это нет.

Теперь, если открыть папку Network and Dial-up Connections, то кроме основного подключения можно увидеть одно или несколько дополнительных, созданных на основе фиктивных сетевых адаптеров. Их следует настроить: в свойствах каждого подключения на закладке General нужно сбросить все флажки, относящиеся к сетевым клиентам, протоколам и службам, за исключением Internet Protocol (TCP/IP). В свойствах протокола TCP/IP необходимо указать IP-адрес и маску подсети из диапазона не используемых в организации локальных IP-подсетей. При этом IP-адреса и маски подсети, назначаемые для каждого подключения, должны образовывать неперекрывающиеся подсети. В приведенном ниже примере фиктивным сетевым адаптерам были назначены адреса 192.168.2.1 и 192.168.2.5 с масками подсетей 255.255.255.252.

Основное подключение по локальной сети также требует настройки. Следует выделить из числа адресов локальной IP-подсети, к которой подключен терминальный сервер, дополнительные IP-адреса по числу добавленных фиктивных сетевых адаптеров. Затем нужно открыть окно свойств протокола TCP/IP, нажать кнопку Advanced и добавить IP-адреса на закладке IP Settings.

Теперь в конфигурацию служб терминалов можно добавить новые объекты Connection. Необходимо запустить консоль Terminal Services Configuration, открыть свойства существующего подключения RDP-Tcp, перейти на закладку Network Adapter и вместо режима по умолчанию — All network adapters configured with this protocol — выбрать из списка физически установленный на сервере сетевой адаптер. Далее, используя мастер Terminal Services Connection Wizard, нужно добавить один или несколько новых объектов Connection, выбирая для каждого из них свой «сетевой адаптер» Microsoft Loopback Adapter. В результате должна получиться конфигурация, подобная показанной на экране 2. Настройку параметров терминальных сессий можно выполнить сразу или позднее.

Осталось настроить службу RRAS для перенаправления пакетов, приходящих на дополнительные IP-адреса сетевого интерфейса, во внутреннюю сеть терминального сервера. Для этого требуется открыть консоль Routing and Remote Access, и, если служба RRAS не была сконфигурирована ранее, выбрать локальный сервер, в меню Action запустить Configure and Enable Routing and Remote Access и при выборе конфигурации указать Network Router. Нам предстоит добавить и сконфигурировать службу NAT, так как именно она обеспечит видимость внутренних «сетевых адаптеров» из «внешней» локальной сети. Для этого в разделе IP Routing нужно выделить General и в меню Action выбрать New Routing Protocol. — Network Addtess Translation (NAT). При настройке следует указать, какие подключения являются внешними, а какие — внутренними. Необходимо добавить все подключения на основе Microsoft Loopback Adapter как внутренние (Private interface connected to private network), а подключение сетевого адаптера к локальной сети — как внешнее (Public interface connected to the Internet). Следует открыть свойства внешнего подключения, перейти на закладку Address Pool и в списке адресов указать основной и все дополнительные IP-адреса локальной сети, назначенные сетевому адаптеру терминального сервера. При добавлении в список единичных адресов (не подсетей) требуется в полях Start Address и End Address указать один и тот же адрес, а поле Mask не заполнять. Далее на закладке Special Ports нужно настроить правила перенаправления пакетов, по аналогии с примером на экране 3.

Экран 4. Seamless Client Publisher — средство публикации приложений

Здесь 192.168.2.1 и 192.168.2.5 — это IP-адреса «устройств» типа Microsoft Loopback Adapter, 10.0.2.11 и 10.0.2.12 — дополнительные адреса локальной сети, привязанные к сетевому адаптеру, а порт 3389 — стандартный порт служб терминалов Windows. Иными словами, все подключения от клиентов служб терминалов по дополнительным IP-адресам перенаправляются на соответствующие фиктивные сетевые адаптеры. Правила перенаправления допустимо настраивать только для дополнительных IP-адресов, иначе перестанет функционировать объект Connection, связанный с основным физическим сетевым адаптером.

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

Другие параметры терминальных сессий

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

Терминальные службы и эмуляция локальных окон

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

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

Рисунок 1. Публикация приложений средствами клиента служб терминалов

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

Очевидно, что представленное решение требует перестройки исключительно клиента служб терминалов. Ни сервер, ни протокол в каких-либо модификациях не нуждаются. В чистом виде такой подход реализован в программе AppliDis Seamless Client французской компании InfoStance. Программа замечательна еще и тем, что при ограничении не более пяти одновременных подключений официально разрешено пользоваться ею бесплатно. Рассмотрим возможности программы более подробно.

Программа AppliDis Seamless Client устанавливается на терминальном сервере Windows 2000 Server или Windows Server 2003. В процессе установки появляется компоновщик Seamless Client Publisher (см. экран 4), который позволяет настраивать предназначенные для публикации приложения. Для каждого приложения можно определить путь к исполняемому файлу, параметры командной строки, домен или локальный сервер, производящий аутентификацию, а также параметры цветовой палитры и перенаправления внешних устройств. После добавления записи в список опубликованных приложений создается компактный (не более 300 Кбайт) исполняемый файл, помещаемый в общий каталог ClientsSeamless. Программный код, содержащийся в файле, осуществляет подключение и запуск заданного приложения в терминальной сессии, но не содержит никаких средств настройки, поэтому в случае изменения параметров опубликованного приложения компоновщик пересоздает файл. Такие файлы можно запускать из общей папки, переносить на рабочие станции, помещать на Web-сервер и т. п.

Опубликованное приложение запускается на клиентском компьютере в отдельном окне без видимых атрибутов терминальной сессии. Если приложение порождает новую задачу, она запускается в своем собственном окне, но в той же самой терминальной сессии. Для подключения к опубликованному приложению необходимо ввести имя пользователя и пароль для аутентификации на терминальном сервере. Имеется режим, позволяющий сохранить введенные реквизиты на рабочей станции в профиле пользователя. В качестве клиентов поддерживаются версии Windows 9x/Me/NT/2K/XP.

Для своей работы программа требует наличия ActiveX-компонента msrdp.ocx версии не ниже 5.2 на всех клиентах и по возможности на сервере. Распространять данный компонент можно различными способами. Например, установить на Web-сервер IIS в локальной сети программное дополнение Remote Desktop Web Connection, последнюю версию которого можно найти на сайте Microsoft. Тогда для установки ActiveX-компонента на клиентских компьютерах достаточно запустить Internet Explorer, обратиться по адресу: http:///tsweb (где вместо следует подставить имя или адрес сервера IIS) и подтвердить загрузку компонента.

Загрузить программу AppliDis Seamless Client можно по адресу. Описанное решение наглядно отражает ситуацию на конкурентном рынке программных продуктов, где качественный сервис предлагается за большую цену, а менее дорогие решения, хотя и справляются с поставленной задачей, но с теми или иными ограничениями. В то же время, как видно из рассмотренного примера, протокол RDP и службы терминалов Windows не имеют принципиальных ограничений по осуществлению полноценной публикации приложений.

Олег Ржевский (osr@trust.ru ) — руководитель проекта в Инвестиционном банке ТРАСТ, к.ф-м.н. Имеет сертификат MCSE.

Поделитесь материалом с коллегами и друзьями