Развертывание Windows Forms

Question

Я пишу приложение Windows Forms, которое будет продаваться малым и средним корпорациям и использоваться пользователями в локальной сети.

Чтобы упростить работу сетевых администраторов, я подумываю использовать .Net 3.5 SP1 и запустить приложение из сетевой папки. Таким образом, установка клиента минимальна (я знаю, что у них должен быть установлен .Net 3.5 SP1).

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

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

Я хочу узнать ваше мнение, если вы использовали такое развертывание, в чем заключаются подводные камни и о чем мне следует знать.

Я немного обеспокоен проникновением .Net 3.5 SP1, но я все время использую LINQ to SQL, поэтому я не думаю, что у меня есть другой выбор.

Заранее спасибо.

Answer 1

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

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

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

Answer 2

Посмотрите здесь: http://weblogs.sqlteam.com/jhermiz/archive/2007/08/14/60284.aspx

Программы .net Framework, работающие на CLR, используют CAS (безопасность доступа к коду). Это означает, что вы больше не назначаете права пользователям / группам в сети. Вместо этого вы назначаете доверие реальному коду, который разработал программист. По сути, ваш файл сборки приложений сравнивается с политикой безопасности компьютера. Когда вы запускаете приложение на локальном компьютере, и оно работает просто замечательно, это связано с тем, что вы выполняете свой код в зоне MyComputer. По умолчанию зона MyComputer имеет FullTrust (неограниченные разрешения) для выполнения практически любых задач. Вот почему приложение работает на вашем локальном компьютере просто отлично ... теперь почему оно не работает на сервере.

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

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

2 способа:

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

Answer 3

Не могли бы вы обойтись без развертывания OneClick? Есть ловушки, о которых нужно знать, но они должны обрабатывать автообновление.

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