我正在使用PnP Composite Application Guidance构建WPF应用程序。该应用程序将在我们的Intranet中本地运行。
模块将根据用户角色动态加载。因此，应用程序必须可以通过网络共享访问这些模块，从而可以从客户端计算机访问这些模块。
我想要做的是将所有模块.dll保存在工作人员无法访问的位置，但仍然能够在需要时以及当前用户通过身份验证使用该模块时将它们提供给复合应用程序。
我的想法是通过从WCF服务流式传输来加载.dll，其中WCF服务（在服务器上）可以访问.dll存储库，但是没有一个客户端计算机可以访问它。身份验证也将由服务处理。
我怀疑我可能会以某种方式过度复杂化。
这可以通过简单的文件系统配置完成，并在访问共享文件夹时以编程方式传递凭据吗？如果我这样做，访问权限只会被授予调用应用程序，或者登录用户现在能够导航到共享文件夹吗？
这是MEF或您知道的任何其他项目的解决问题吗？ （我希望这不是LMGTFY值得的 - 我无法想出任何东西。）
答案 0 :(得分：3)
在阿贡国家实验室，我们将所有可共享的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和其他供应商）对我们的解决方案有些困惑，但是看到我们部署的每个部署技术供应商都得出了相同的结论，基本上是：“你不需要我们”。
答案 1 :(得分：1)
加载模块时，您需要记住：
加载后，无法卸载程序集（除非您卸载整个应用程序域） - 因此，如果用户可以使用同一实例登录和注销，则可能会出现问题。
< / LI>“加载上下文”很重要（参见http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx） - 如果模块之间存在依赖关系，或者不在“加载上下文”中的程序集依赖关系，这可能会导致问题
如果限制访问dll是由于许可问题，可能您需要以某种方式优化许可机制（不是将其绑定到实际代码的访问权限，而是用于其他一些检查）？