Развертывание .EXE на сетевой диск?

В чем проблема с развертыванием .EXE на сетевом диске и выполнение пользователями .EXE по сети?

Преимущество заключается в том, что обновления необходимо только в одном месте. Каковы недостатки?

Ответ 1

Вместо этого я подумал о создании файла MSI (http://en.wikipedia.org/wiki/Windows_Installer) для вашего приложения и групповой политики для облегчения распространения по всей вашей компании (http://support.microsoft.com/kb/816102).

Существует ряд бесплатных инструментов MSI. Хорошие, которые приходят на ум, - это http://www.advancedinstaller.com/ и http://wix.codeplex.com/

Ответ 2

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

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

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

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

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

Если вы действительно хотите пойти по этому пути, вам, возможно, следует рассмотреть альтернативы, такие как удаленный рабочий стол (например, Citrix или Terminal Server) или что-то в этом роде - есть гораздо лучшие способы достижения ваших целей, чем просто прикрепить все на сетевой диск.

Ответ 3

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

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

Ответ 4

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

Ответ 5

Если вы пишете свое приложение, используя модель безопасности объектов, как это определено в Ph.D. Марка С. Миллера тезис, Надежная композиция: на пути к унифицированному подходу к контролю доступа и параллелизму у вас не будет никаких недостатков безопасности.

С другой стороны, "недостатком" является то, что теперь вы должны управлять контролем доступа через граф объектов. Приложение должно иметь доступ только к тем разрешениям, которые вы ему предоставляете. Как уже упоминалось, в Windows есть базовая политика защиты, которая блокирует файлы приложения и, таким образом, запрещает кому-либо изменять EXE до тех пор, пока экземпляры приложений не будут закрыты.

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

Понимать последствия этого и делать это хорошо - задача не из легких.

Ответ 6

Основным недостатком будет отсутствие сетевого диска.

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

Ответ 7

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

К счастью, мое приложение будет развернуто только на отдельных рабочих станциях.:)

Ответ 8

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

Ответ 9

Я запускаю приложение поставщика, как это на работе. Они не проектировали для этого, но это работает без проблемы. У меня есть все короткие пути, указывающие на путь UNC. Это конкретное приложение не использует файлы в каталоге exe, поэтому блокировка файлов не является проблемой. Он также подключен к SQL Server для данных, поэтому хранилище данных также не является проблемой. (Будет серьезной проблемой, если приложение будет использовать локальную базу данных SQLite, Access или какую-либо другую файловую БД.)

Если ваше приложение является приложением .Net, оно НЕ БУДЕТ работать без каких-либо серьезных изменений в настройках безопасности каждого компьютера, что в любом случае, вероятно, является плохой идеей. Если вы говорите о приложении .Net, вы должны использовать ClickOnce. Я также использую его для нескольких приложений на работе, и он великолепен и прост в использовании.

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

Ответ 10

Это прекрасно выполнимо. Обязательно установите флажок "Выполнить с компакт-диска" (я думаю?) В настройках Visual Studio при компиляции - это предотвращает резервное копирование изображения непосредственно с помощью двоичного файла, поэтому вы можете обновить его, пока люди его запускают. Я не запускаю Windows на данный момент, поэтому я не могу проверить, но вы также можете установить этот флаг для библиотек DLL.

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

Еще одна серьезная проблема заключается в том, что если кто-то случайно разворачивает сломанную версию, это не только ранние усыновители, которые получают чучело!

Для легкой жизни лично я рекомендую развертывание XCOPY...

Ответ 11

Для приложений .NET мы наблюдали BadImageFormatException, которые, как нам полагают, связаны с сетевыми сбоями (или компьютеры теряют сетевое подключение в ключевые моменты, например, с использованием WIFI) при чтении EXE или DLL файлов.

Ответ 12

ИМХО это действительно плохое дизайнерское решение. В нашей компании есть стороннее приложение, которое разработано именно так.

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

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