当 GAC 中已存在相同版本时，程序集私有部署出现问题报告查看器
我们有一个使用 Report Viewer 2010 的单击一次 WinForms 应用程序。这些程序集是私有部署的 - 也就是说，我们不对它们进行 GAC（AFAIK，这是最佳实践，尽管我可能是错的）。
我们遇到了以下问题。我们需要报表查看器文件版本 10.0.40219.1（我相信这是来自 VS2010 SP1） - 它修复了一些 RTM 版本 (10.0.30319.1) 没有的错误。然而，在我们部署的某些机器上，“坏”（旧）程序集已经在 GAC 中（例如，如果用户安装了 VS2010 RTM 或决定 GAC 报告查看器的任何其他软件 - TFS 会这样做，我相信）。不幸的是，两个程序集的程序集版本是相同的，10.0.0.0。因此，CLR 加载程序始终选择 GAC 程序集而不是本地部署的程序集。
据我了解，无论如何，所有 Assembly.Load…() 方法都会首先从 GAC 加载，因此手动预加载程序集并不能真正帮助我们。我能看到的唯一解决方案是 GAC 我们正在部署的 ReportViewer 程序集，但这听起来不是正确的做法。
问题：我们确保加载正确的报表查看器程序集的正确方法是什么？
谢谢，
戴夫。
We have a click-once WinForms application that is using the Report Viewer 2010. The assemblies are privately deployed – that is, we do not GAC them (AFAIK, this is the best practice, although I might be wrong).
We are running into the following problem. We require Report Viewer file version 10.0.40219.1 (I believe this is from VS2010 SP1) – it has some bug fixes that the RTM version (10.0.30319.1) does not have. However, one some machines we deploy to, the “bad” (older) assembly is already in the GAC (for example, if the user has installed VS2010 RTM or any other software that decides to GAC the Report Viewer – TFS does that, I believe). Unfortunately, the assembly version of both assemblies is the same, 10.0.0.0. Because of this, the CLR loader ALWAYS picks the GAC assembly over the locally deployed one.
As far as I understand, all Assembly.Load…() methods will load from the GAC first, no matter what, so pre-loading the assembly manually won’t really help us. The only solution I can see is to GAC the ReportViewer assembly we are deploying – but that does not sound like the right thing to do.
Question: what is the proper way for us to ensure the correct Report Viewer assembly gets loaded?
Thanks,
Dave.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，现在你可以粗暴地玩了。如果您完全信任，您可以挂钩 CreateFileW 以打开本地副本而不是 GAC 中的副本；但是，如果它已被ngen'ed，则不起作用。
您当然可以挂接注册表函数，这样扫描 GAC 时就找不到它。
如果相关程序集是纯托管代码，您可以通过 ildasm 运行它，更改私钥，通过 ilasm 运行它，对其进行签名，然后链接到它。
Well now you get to play rough. If you have full trust you can hook CreateFileW to open the local copy instead of the one in the GAC; however if it's been ngen'ed that won't work.
You could of course hook the registry functions so scanning the GAC for it doesn't find it.
If the assembly in question is pure managed code, you could run it through ildasm, change the private key, run it through ilasm, sign it, and link to that.
Assembly.LoadFile(path) 将加载您想要的文件。
编辑：错误。
Assembly.LoadFile(path) will load the one you want.
EDIT: wrong.