Динамически загружать DLL-файлы из общей сетевой папки, недоступной для просмотра на клиентском ПК - WCF?

Question

Я проектирую приложение WPF, используя Руководство по составному приложению PnP. Приложение будет запускаться локально, в нашей внутренней сети.

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

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

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

Я подозреваю, что я как-то слишком усложняю вещи.

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

Это, в любом случае, решаемая проблема с MEF или любым другим проектом, о котором вы знаете? (Надеюсь, это не достойно LMGTFY - я ничего не смог придумать.)

Answer 1

В Аргоннской национальной лаборатории мы храним все разделяемые библиотеки DLL и другие объекты (файлы .INI, библиотеки PowerBuilder PBD, прикладное программное обеспечение и т. Д.) На простом и общедоступном файловом сервере, и объекты загружаются по сети по мере необходимости. основа, как определено каждым клиент-серверным приложением. Таким образом, мы сводим к минимуму обслуживание промежуточного программного обеспечения (Oracle Client, PowerBuilder, Java, Microsoft, ODBC и т. Д.) В одном месте на файловом сервере, и на ПК конечного пользователя практически не установлено программное обеспечение. Как правило, мы физически загружаем менее нескольких КБ ключей реестра на отдельный компьютер конечного пользователя; это включает в себя полный клиент Oracle, который, если он будет установлен только на ПК, займет 650+ МБ дискового пространства и несколько тысяч ключей реестра и будет дорогостоящим в обслуживании на предприятии. Вместо этого наш клиент Oracle на ПК составляет около 17 КБ.

Единственным «программным обеспечением» на стороне клиента являются ключи реестра, содержащие переменные, указывающие на расположение серверов (например, ORACLE_HOME: \<server name>\ORACLE\v10\Ora10g).

Это очень экономичное решение, которое мы используем уже более 10 лет, благодаря чему все обновления промежуточного и прикладного программного обеспечения полностью прозрачны для более чем 2000 пользователей в лаборатории. За прошедшие годы мы выполнили тысячи обновлений объектов на центральном файловом сервере, не устанавливая ни одного обновления на рабочем столе конечного пользователя. Несмотря на то, что это сопряжено с некоторыми рисками («вы не должны копировать библиотеки DLL по сети» и т. Д.) И является сильно настроенным решением, оно работало для нас безупречно для большого числа приложений и промежуточного программного обеспечения.

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

Answer 2

при загрузке модулей вы должны иметь в виду, что:

• После загрузки сборка не может быть выгружена (если вы не выгружаете весь домен приложения) - поэтому, если пользователи могут входить и выходить из одного экземпляра, у вас могут возникнуть проблемы.

• имеет значение «контекст загрузки» (см. http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx) - это может вызвать проблемы, если у вас есть зависимости между модулями или зависимости от сборок, не входящих в «контекст загрузки»

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