Развертывание приложений.Net
Я пишу приложение Windows Forms для малых и средних корпораций, которое будет использоваться пользователями в локальной сети.
Чтобы упростить работу сетевых администраторов, я подумываю использовать.Net 3.5 с пакетом обновления 1 (SP1) и иметь приложение, работающее с сетевого ресурса. Таким образом, установка клиента минимальна (я знаю, что у них должен быть установлен.Net 3.5 SP1).
Администратор установит приложение на сервер, запустив установщик Windows, а затем отправит пользователям по электронной почте путь к сетевому пути, чтобы они могли начать использовать приложение. Альтернатива состоит в том, чтобы администратор установил приложение на сотни компьютеров, чего я стараюсь избегать. Каждый раз, когда я обновляю приложение, администратору остается только переустановить его на одном сервере.
Я хочу узнать ваше мнение, если вы использовали такое развертывание, какие подводные камни и о чем я должен знать.
Заранее спасибо.
8 ответов
Как правило, я бы предпочел, чтобы вы просто упаковывали приложение в пакет установщика Windows (MSI). Я могу безболезненно развернуть это на любом количестве компьютеров всего за несколько минут.
Я предпочел бы иметь приложение на жестких дисках моих компьютеров, а не сидеть в "общей папке" на сервере. Хорошие шансы, что приложение будет запускаться очень плохо, если "общая папка" на сервере находится через медленную линию WAN, но пользовательский опыт приложения в отношении доступа к удаленной базе данных SQL Server может быть приемлемым по той же линии WAN, Поэтому я бы предпочел приложение на жестком диске ПК.
Я также считаю, что пропускная способность локальной сети является ценным товаром, и перетаскивание программы по проводам при каждом запуске пользователя кажется мне расточительным.
Вы должны посмотреть на развертывание ClickOnce. Описание Википедии.
+1 для развертывания clickonce. Я использую это для управления 3 приложениями более 100+ компьютеров в 4 странах.
Эван делает очень хорошие замечания. Я также хотел бы остановиться на вашем процессе обновления: хотя я понимаю, что вы хотите упростить процесс обновления, это может быть опасно. Просто не легко.
Я (как администратор) хотел бы видеть установщик MSI (с деинсталлятором). Обновления должны быть обработаны таким же образом. Таким образом, наш процесс установки также может быть нашим процессом обновления.
Могу ли я также добавить ваш первый запрос функции? Сделайте параметр реестра, который содержит информацию о версии приложения. Это должно быть установлено во время установки и сброшено во время обновлений. Хотя это и не большой поклонник реестра в целом, это парадигма Windows. Это намного проще, чем проверка версии DLL (или любых файлов, которые вы будете использовать).
Большое спасибо, что спросили нас, сисадминов, что мы хотим. Пожалуйста, возвращайтесь, когда у вас возникнут вопросы, и приведите своих друзей.
Я хотел бы добавить, что приложение.NET, выполняемое по сетевому пути, работает с низким уровнем привилегий. В зависимости от того, что делает ваше приложение, это может не иметь большого значения. Но вы должны проверить это, прежде чем выбрать этот путь. В этой теме есть хорошие предложения - Нажмите Один раз, MSI и развертывание через объект групповой политики. Я могу сказать, что использовал их все в некотором качестве. С Click Once вам не нужно много помощи от администратора, за исключением настройки виртуального каталога для размещения вашего приложения форм.
Я определенно предложил бы вам ИЗБЕГАТЬ этого. Если вы планируете запускать ваше приложение через общий сетевой ресурс, то вы можете воспользоваться сетью Windows, когда происходит сбой. Общие папки Windows работают медленно и часто не надежны, когда многие пользователи обращаются к одной и той же папке. Это связано с его сложной сетевой моделью.
У меня есть приложение, которое читает файлы с общего ресурса. Часто мы получаем случайные ошибки, которые блокируют нас от доли. Есть множество проблем, которые просто ставят в тупик. Я настоятельно рекомендую вам избегать превышения доли.
Могу я порекомендовать другое решение? Перекодируйте ваш пользовательский интерфейс, чтобы стать веб-сервисом. Затем запустите ваше приложение на веб-сервере. Ваши клиенты могут использовать браузер для использования вашего приложения. Winforms могут быть легко преобразованы в веб-формы.
Риск получить удар по голове, я бы предпочел, чтобы вы разрабатывали свое приложение для конечного пользователя, а не для системного администратора. У меня есть несколько причин для этого:
Что делать, если нет сети? Вы ограничиваете свою потенциальную клиентскую базу, если ваше приложение не может быть установлено и работать полностью на одной машине.
А как насчет компаний, которые не имеют сетевых администраторов? Сколько будет работать, чтобы кто-то, кто обычно обрабатывает кредиторскую задолженность, выполнял ваши установки и обновления? Возможно, им понадобится нанять консалтинговую компанию, чтобы помочь им, поэтому вы только что добавили TCO для своего приложения. Вы также сделали свое приложение зависимым от наличия определенной инфраструктуры.
Нет ничего, что я ненавижу больше, чем приложение, которое должно запускаться из общего сетевого ресурса. Загрузка exe и DLL по сети - рецепт проблем. Кратковременная потеря связи или перегрузка, и ваше приложение перестает работать правильно, потому что оно потеряло соединение с необходимыми исполняемыми файлами, библиотеками DLL и т. Д.
Я системный администратор, я бы хотел, чтобы моя работа была легкой, но иногда это не так, и это факт работы. Иногда моя работа требует от меня посещения конечных пользователей для установки и обновления программного обеспечения. Если я не хочу этого делать, то я, вероятно, не в том направлении.
Когда вы строите автомобили, вы создаете их для потребителя, а не для механика.
Ну, этот вид развертывания очень устоялся, он использовался с незапамятных времен. Конечно, он работает нормально, но явно создает большую нагрузку на сеть, если он находится в офисе, где нет ничего, кроме 100 МБ /1 ГБ соединений и достаточной емкости сервера, тогда все будет хорошо, но работать через Интернет будет больно или соединение с низкой пропускной способностью.