我正在使用 PnP 复合应用程序指南构建 WPF 应用程序。该应用程序将在我们的 Intranet 中本地运行。
模块将根据用户角色动态加载。因此，应用程序必须可以通过网络共享访问这些模块，从而可以从客户端计算机访问这些模块。
我想做的是将所有模块 .dll 保存在工作人员无法访问的位置，但仍然能够在需要时以及当前用户经过身份验证以使用该模块时将它们提供给复合应用程序。
我的想法是通过从 WCF 服务流式传输 .dll 来加载它们，WCF 服务（在服务器上）可以访问 .dll 存储库，但没有任何客户端机器可以访问它。身份验证也将由服务处理。
我怀疑我可能以某种方式使事情过于复杂。
这是否可以通过简单的文件系统配置并在访问共享文件夹时以编程方式传递凭据来完成？如果我这样做，是否只会向调用应用程序授予访问权限，还是登录用户现在能够导航到共享文件夹？
无论如何，这是 MEF 或您知道的任何其他项目的已解决问题吗？（我希望这不值得 LMGTFY ——我无法想出任何东西。）
在阿贡国家实验室，我们将所有可共享的 DLL 和其他对象（.INI 文件、PowerBuilder PBD 库、应用软件等）保存在一个简单的内部公共文件服务器上，并根据定义根据需要通过网络下载对象由每个客户端/服务器应用程序。因此，我们将中间件（Oracle 客户端、PowerBuilder、Java、Microsoft、ODBC 等）的维护降至最低，最终用户 PC 上基本上没有安装任何软件。通常，我们将少于几 KB 的注册表项物理下载到个人最终用户 PC；这包括完整的 Oracle 客户端，如果单独安装在 PC 上将占用 650+ MB 磁盘空间和数千个注册表项，并且在企业中维护成本很高。相反，我们在 PC 上的 Oracle 客户端大约为 17KB。
客户端唯一的“软件”是注册表项，其中包含指向服务器位置（f.ex. ORACLE_HOME: \<server name>\ORACLE\v10\Ora10g）的变量。
这是我们使用了 10 多年的非常经济高效的解决方案，使所有中间件和应用程序软件升级对实验室范围内的 2000 多个用户完全透明。多年来，我们在中央文件服务器上完成了数千次对象升级，而无需在最终用户桌面上安装一次升级。尽管这有一些风险（“您不得通过网络复制 DLL”等）并且是一个高度定制的解决方案，但它对我们的大量应用程序和中间件始终有效。
在当今的先进技术中，这是一个有点令人惊讶的简单解决方案，但它对我们来说是完全高效且具有成本效益的。几家供应商（Citrix 等）对我们的解决方案感到有些困惑，但每个看过我们部署的部署技术供应商都得出了相同的结论，基本上是：“你不需要我们”。
加载模块时，您需要记住：
一旦加载，程序集就不能被卸载（除非你卸载整个应用程序域）——所以如果用户可以使用同一个实例登录和注销，你可能会遇到问题。
“加载上下文”很重要（请参阅http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx） - 如果您在模块之间存在依赖关系或对不依赖的程序集有依赖关系，这可能会导致问题在“加载上下文”中
如果对 dll 的访问受限是由于许可问题，也许您需要以某种方式改进许可机制（不是将其与对实际代码的访问联系起来，而是与其他一些检查联系起来）？