如何使用配置操作私有文件夹中的多个程序集版本?
我有一个场景,我有同一个程序集的多个版本,我需要将其存储在应用程序私有文件夹中,结构如下:
.\My.dll // latest version, say 1.1.3.0
.\v1.1.1\My.dll // version 1.1.1.0
.\v1.1.2\My.dll // version 1.1.2.0
我的问题是,.Net 运行时,当要求提供旧版本之一时,总是会找到最新版本,然后由于内部版本号不匹配而失败,然后再尝试探测更好的匹配。
这些程序集是强命名的,我在我的 app.config 中使用此配置:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="My"
publicKeyToken="xxxxxxxx" culture="netural" />
<bindingRedirect oldVersion="1.0.0.0-1.1.1.0"
newVersion="1.1.1.0" />
<bindingRedirect oldVersion="1.1.3.0-1.1.65535.65535"
newVersion="1.1.3.0" />
<codeBase version="1.1.1.0" href="v1.1.1\My.dll" />
<codeBase version="1.1.2.0" href="v1.1.2\My.dll" />
</dependentAssembly>
</assemblyBinding>
</runtime>
希望我在这里遗漏了一些东西。 我知道这可以通过监听 AppDomain 来解决。 AssemblyResolve 事件,但我希望看到一个纯粹的配置解决方案。
更新:所以我发现了这个错误,正如肯特所认为的,这是一个拼写错误。 culture="netural"
应为 culture="neutral"
。 也就是说,如果没有拼写错误,当使用指向每个版本的 codeBase
元素时,解析效果很好。 探测元素在这种情况下似乎不起作用。
I have a scenario where I have multiple versions of the same assembly that I need to store in the application private folders, in a structure like this:
.\My.dll // latest version, say 1.1.3.0
.\v1.1.1\My.dll // version 1.1.1.0
.\v1.1.2\My.dll // version 1.1.2.0
My problem is that the .Net runtime, when asked for one of the older versions, always finds the latest version and then fails due to build number mismatch before trying to probe for a better match.
The assemblies are strong named and I'm using this configuration in my app.config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="My"
publicKeyToken="xxxxxxxx" culture="netural" />
<bindingRedirect oldVersion="1.0.0.0-1.1.1.0"
newVersion="1.1.1.0" />
<bindingRedirect oldVersion="1.1.3.0-1.1.65535.65535"
newVersion="1.1.3.0" />
<codeBase version="1.1.1.0" href="v1.1.1\My.dll" />
<codeBase version="1.1.2.0" href="v1.1.2\My.dll" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Hopefully there is something I have missed here. I know this can be solved in code by listening for the AppDomain.AssemblyResolve event but I would love to see a pure config solution.
Update: So I found the bug, which is as Kent assumed, a typo. culture="netural"
should be culture="neutral"
.
That said, without the typo, resolving works great when using codeBase
elements that point to each version.
The probing element does not seem to work in this scenario.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在没有看到整个解决方案的情况下,我只能假设你在某个地方有错字。 我只是自己尝试过这个 - 在 fuslogvw 的帮助下,我能够让它工作。
我有三个版本的程序集,并且使用应用程序引用的版本比其输出目录中的版本旧。 CLR 找到重定向和 codeBase 条目并加载正确的(旧的)版本。
如果您提供电子邮件地址,我可以通过电子邮件向您发送我的解决方案。
肯特
Without seeing the entire solution, I can only assume you have a typo somewhere. I just tried this for myself and - with the help of fuslogvw, I was able to get it working.
I have three versions of the assembly and the consuming application references an older version than that in its output directory. The CLR finds the redirects and codeBase entry and loads the correct (older) version.
I can email you my solution if you provide an email address.
Kent
你可以使用探针路径吗? 我们使用它来强制不受控制的(例如第三方解析器 - 例如 MSTest)在我们需要的地方寻找程序集。
有关详细信息,请参阅此处
Can you use a probepath? we use this to force uncontrolled (e.g. third party resolvers - such as MSTest) to look for assemblies where we need them to be.
See here for more info