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

Question

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

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

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

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

Я подозреваю, что, возможно, я как бы преувеличиваю.

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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