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

Question

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

Чтобы упростить работу с сетевыми администраторами, я подумываю использовать .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 deploy, но все они имеют проблемы.

Answer 2

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

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

Answer 3

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

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

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

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

2 способа являются:

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