.NET 程序集加载问题
我正在维护我们的应用程序的构建过程，该过程由 ASP.Net 应用程序、两个不同的 Win32 服务和其他与系统管理相关的应用程序组成。
我想最终得到以下配置，以便在调试和调试时使用。部署。
libraires/ -- Contains shared assemblies used by all other apps.
web/ -- ASP.Net site
service1/ -- Win32 service 1 (seen under the service control manager)
service2/ -- Win32 service 2
adminstuff/ -- Sysadmin / support stuff used for troubleshooting
问题是 app.config 中的程序集探测 privatePath 不支持应用程序根目录之外的相对目录。即：无法使用../libraries。非常令人沮丧...
如果我强命名我们的程序集，我可以使用 codeBase 配置元素，它似乎支持绝对路径，但您需要单独指定每个程序集。
我还尝试挂钩 AppDomain.AssemblyResolve 事件，但在我可以在 Main() 中注册事件处理程序之前，我从 .Net Fusion 收到 FileNotFoundException。
我不喜欢在 GAC 中注册程序集的想法。部署/升级应用程序时太麻烦。
是否有另一个可以在不指定每个所需程序集的路径的情况下执行此操作？
I'm maintaining the build process for our application which consist of an ASP.Net application, two different Win32 services and other sysadmin related applications.
I want to end up with the following configuration to be used both when debugging & deploying.
libraires/ -- Contains shared assemblies used by all other apps.
web/ -- ASP.Net site
service1/ -- Win32 service 1 (seen under the service control manager)
service2/ -- Win32 service 2
adminstuff/ -- Sysadmin / support stuff used for troubleshooting
The problem is assembly probing privatePath in the app.config does not support relative directories outside the application root. Ie: can't use ../libraries. Very frustating...
If I strong name our assemblies, I could use codeBase config element which seems to support absolute path but you need to specify each assembly individually.
I also tried hooking into AppDomain.AssemblyResolve event, but I'm getting FileNotFoundException from the .Net Fusion before I can even register the event handler in Main().
I don't like the idea of registering the assemblies in the GAC. Too much hassle when deploying / upgrading application.
Is there another to do this without having the specify the path of each requiered assembly ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你的方法会调用最糟糕的 DLL Hell。更新“库”程序集可能会破坏所有未经测试的应用程序，并且无法通过让它们使用旧版本的程序集来修复它们。这就是 CLR 不支持这种情况的原因。
您已经列出了所有常见的解决方法。但有一点除外：为每个应用程序提供自己的副本。
Your approach invokes the worst kind of DLL Hell. Updating a "library" assembly can break all untested apps with no way to get them to repaired by letting them use the old version of the assembly. That's why the CLR doesn't support this scenario.
You've listed all the usual workarounds. Except one: give each app its own copy.
我过去使用过 AppDomain.AssemblyResolve 方法，效果很好。我建议尝试找出导致 FileNotFound 异常的 Assembly，看看是否可以重新组织应用程序初始化，以便在加载时不会加载。
I've used the AppDomain.AssemblyResolve approach in the past and it worked quite well. I would suggest trying to figure out what Assembly is causing the FileNotFound exception as see if you can reorganize application initialization such that it doesn't load when it does.