从网络共享动态加载无法在客户端 PC 上浏览的 .dll — WCF？
我正在使用 PnP 复合应用程序指南构建 WPF 应用程序。该应用程序将在我们的内联网中本地运行。
模块将根据用户角色动态加载。因此，应用程序必须可以通过网络共享访问这些模块，从而可以从客户端计算机进行访问。
我想要做的是将所有模块 .dll 保存在工作人员无法访问的位置，但仍然能够在需要时以及当前用户经过身份验证以使用该模块时将它们提供给复合应用程序。
我的想法是通过从 WCF 服务流式传输 .dll 来加载它们，其中 WCF 服务（在服务器上）可以访问 .dll 存储库，但没有客户端计算机可以访问它。身份验证也将由该服务处理。
我怀疑我可能把事情变得过于复杂了。
这可以通过简单的文件系统配置并在访问共享文件夹时以编程方式传递凭据来完成吗？如果我这样做，是否只会向调用应用程序授予访问权限，或者登录用户现在是否能够导航到共享文件夹？
无论如何，这是 MEF 或您所知道的任何其他项目的已解决问题吗？ （我希望这不值得 LMGTFY ——我什么也想不出来。）
I'm architecting a WPF application using the PnP Composite Application Guidance. The application will be run locally, within our intranet.
Modules will be loaded dynamically based on user roles. The modules must therefore be accessible to the application through a network share, thus accessible from the client machines.
What I'd like to do is keep all the module .dlls in a location not accessible to staff, but still be able to provide them to the composite application when demanded and when the current user is authenticated to use that module.
My thought is to load the .dlls by streaming them down from a WCF service, where the WCF service (on the server) can access the .dll repository, but none of the client machines can access it. Authentication would also be handled by the service.
I suspect that I might be overcomplicating things somehow.
Is this something that can be done with a simple filesystem configuration and programmatically passing credentials when accessing the shared folder? If I do this, would access only be granted to the calling application, or would the logged-on user now be able to navigate to the shared folder?
Is this, in any way, a solved problem with MEF or any other project of which you're aware? (I hope this isn't LMGTFY-worthy -- I haven't been able to come up with anything.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在阿贡国家实验室，我们将所有可共享的 DLL 和其他对象（.INI 文件、PowerBuilder PBD 库、应用软件等）保存在一个简单的内部公共文件服务器上，并且根据定义的需要通过网络下载对象由每个客户端/服务器应用程序。因此，我们将中间件（Oracle Client、PowerBuilder、Java、Microsoft、ODBC 等）的维护工作最小化到单个文件服务器位置，并且最终用户 PC 上基本上没有安装任何软件。通常，我们会将不到几 KB 的注册表项物理下载到个人最终用户 PC；这包括完整的 Oracle 客户端，如果仅安装在 PC 上，将占用 650+ MB 的磁盘空间和数千个注册表项，并且企业的维护成本高昂。相反，我们 PC 上的 Oracle 客户端大约为 17KB。
客户端上唯一的“软件”是包含指向服务器位置的变量的注册表项（例如
ORACLE_HOME: \\ORACLE\v10\Ora10g ）。我们已经使用了 10 多年的极具成本效益的解决方案，使所有中间件和应用软件升级对实验室范围内的 2000 多个用户完全透明。多年来，我们已经在中央文件服务器上完成了数千次对象升级，而无需安装。在最终用户桌面上进行一次升级虽然这存在一些风险（“您不得通过网络复制 DLL”等）并且是一个高度定制的解决方案，但它对于我们的大量应用程序来说一直完美无缺。 在当今的先进技术中，这是一个令人惊讶的简单解决方案，但它对我们来说非常高效且具有成本效益，一些供应商（Citrix 和其他供应商）对我们的解决方案感到有些困惑，但每个部署
技术供应商都见过。我们的部署得出了相同的结论，基本上是：“你们不需要我们”。
At Argonne National Laboratory we keep all sharable DLL and other objects (.INI files, PowerBuilder PBD libraries, application software, etc.) on a simple and internally public file server and objects are being downloaded over the network on a per need basis as defined by each client/server application. Thus we are minimizing the maintenance of middleware (Oracle Client, PowerBuilder, Java, Microsoft, ODBC, etc.) to a single file server location with basically no software installed on the end user PC. Typically we physically download less than a few KB Registry Keys to the individual end user PC; this includes the full Oracle Client, which if installed on the PC alone would take up 650+ MB disk space and several thousand Registry Keys, and costly to maintain on the enterprise. Instead our Oracle Client on the PC is about 17KB.
The only “software" on the client side are Registry Keys containing variables pointing to server locations (f.ex.
ORACLE_HOME: \<server name>\ORACLE\v10\Ora10g).This has been a very cost effective solution we have been using for 10+ years, making all middleware and application software upgrades totally transparent to more than 2000 users Lab wide. Over the years we have done thousands of object upgrades on the central file server without ever having to install a single upgrade on the end user Desktop. Although this has some risks (“thou shall not copy DLLs over the network”, etc.) and is a heavily customized solution, it has worked flawlessly for us throughout for a large number of applications and middleware.
This is a somewhat surprisingly simple solution in today’s advanced technology, but it has been totally efficient and cost effective for us. Several vendors (Citrix and others) have looked at our solution somewhat perplexed, but every vendor of deployment techniques who have seen our deployment has come to the same conclusion, basically: “you do not need us”.
加载模块时，您需要记住：
一旦加载，程序集就无法卸载（除非您卸载整个应用程序域） - 因此，如果用户可以使用同一实例登录和退出，您可能会一个问题。
“加载上下文”很重要（请参阅http:// /blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx) - 如果模块之间存在依赖关系或不在“加载上下文”中的程序集存在依赖关系，这可能会导致问题< /p>
问题对 dll 的访问受限是由于许可问题，也许您需要以某种方式改进许可机制（不是将其与对实际代码的访问联系起来，而是与其他一些检查联系起来）？
when loading modules you need to keep in mind that:
Once loaded, an assembly can't be unloaded (unless you unload the entire application domain) - so if users can log in and out using the same instance, you may have a problem.
"the load context" matters (see http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx) - this may cause problems if you have dependencies between modules or dependencies on assemblies that are not in the "load context"
If the restricted access to dlls is due to a licensing issue, maybe you need to refine the licensing mechanism somehow (not tie it to access to the actual code, but to some other checks)?