使用新的 .net dll 更新应用程序会出现 FileLoadException？
我有一个包含许多 dll 的 .net 3.5 应用程序，我尝试在不构建整个应用程序的情况下重建特定的 dll，但是在用新的替换旧的应用程序后，应用程序抛出异常，因为它无法加载新的 dll 例外： System.IO.FileLoadException：无法加载文件或程序集.... 我知道它会搜索具有特定版本和公共令牌的程序集，如何在不再次构建应用程序的情况下解决此问题？该申请也已签署但未在 GAC 中注册。 附： 我怎样才能跳过再次构建应用程序，或者在重建 dll 时必须这样做？
I have a .net 3.5 application with many dlls, I tried to rebuild specific dll without building the whole application, but after replacing the old one with the new, the application throws exception as it could not load the new dll
exception:
System.IO.FileLoadException: Could not load file or assembly ....
I understand it searches for assembly with specific version and public token, how can I solve this problem without building the application again? also the application is signed but not registered in GAC.
P.S:
How can I skip building the app again, or it is a must as the dll is rebuilt?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您收到错误的原因是您的程序集已签名，并且很可能您对它的引用将“特定版本”属性设置为 True，并且您进行更改的程序集的版本号已更改。我尝试了很多场景，这是我能够获得 FileLoadException 的唯一场景。如果您将目标框架更改为较新的版本（例如 4.0），您将收到 BadImageFormatException。即使您说您没有更改版本号，也请检查它，或者通过选择您的参考，然后右键单击并选择属性，将特定版本设置为 False。
您的异常可能如下所示：
但是，如果引用的程序集不再是 1.0.0.0（或例如任何版本），则您的编译版本。在下图中（虽然很小），您可以看到引用属性正在查找版本 1.0.0.0，特定版本设置为 True，并且引用程序集已签名并且实际上是版本 2.0.0.0，从而导致 FileLoadException。
通过更改版本号并重新编译，或将 Specific Version 设置为 False 并仅重建该 DLL 来解决此问题。您不必重建整个应用程序。
The reason you get the error is because your assembly is signed, and most likely your reference to it has the Specific Version property set to True, and your version number of the assembly you made the change to has changed. I tried many scenarios, and this was the only scenario I was able to get the FileLoadException. If you had changed the Target Framework to a newer version like 4.0, you would get a BadImageFormatException instead. Even if you say you didn't change the version number, check it anyway, or set Specific Version to False by selecting your reference, and right clicking and selecting properties.
Your exception likely looked like this:
But your compiled version if the assembly that is being referenced is no longer 1.0.0.0 (or whatever version, for example). In the image below (beit small), you can see that the reference property is looking for version 1.0.0.0, Specific Version is set to True, and the reference assembly is signed and is actually version 2.0.0.0, thus resulting in FileLoadException.
Resolve this by changing the version number back and recompiling, or setting Specific Version to False and rebuilding only that DLL. You do not have to rebuild your entire application.
您是否尝试使用 DEVPATH 环境变量？此环境变量允许您定义一个目录来充当“开发期间的 GAC”。您所要做的就是：
1) 将以下元素添加到您的 machine.config（仔细检查将使用 machine.config 的位置）
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG*
2) 添加名为 DEVPATH 的新环境变量
3) 然后执行添加到您的 UI 应用程序/项目并在 DEVPATH 目录中添加对 dll 的引用。
确保您配置了“本地副本 = false，特定版本 = false” >。正如您可能会看到的，强名称（Starker Name）是true。
4) 现在您必须编译一次 UI 应用程序！之后，您可以选择根据需要更改 DLL 中的源代码。由于 DEVPATH 变量的存在，您的 UI 应用程序将始终选择最新版本的 DLL！
注意！ 我尝试从 VS 启动 UI 应用程序，但因加载异常而失败。但从资源管理器窗口启动它 - 成功了。似乎从 VS 启动 UI 应用程序会导致 CLR 在其他地方查找引用的 DLL。
您也可以查看 MSDN 和 MSDN2。
备注：
仅在开发时使用此设置。运行时不检查版本
在 DEVPATH 中找到的强名称程序集。它只是使用它找到的第一个程序集。
您也可以查看以下文章/网页。
CodeProject - 程序集位置、绑定、部署
社交 MSDN 问题DEVPATH
我认为这应该可以解决问题！
Did you try to make use of DEVPATH environment variable? This environment variable allows you to define a directory to act as "GAC during development". All you have to do is:
1) Add the following element to your machine.config (Double check what location of your machine.config is going to be used)
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG*
2) Add a new environment variable with the name DEVPATH
3) Afterwards go to your UI App/Project and add a reference to your dll in the DEVPATH directory.
Make sure that you configured "local copy = false, specific version = false". As you might see Strong name (Starker Name) is true.
4) Now you have to compile your UI application ONCE! After that you may choose to change your source in your DLL as you wish. Because of the DEVPATH variable, your UI application will always choose the latest build of your DLL!
NOTE! I tried to start the UI application from VS but failed with load exception. BUT starting it from the explorer windows - succeeded. Seems that starting the UI application from VS causes the CLR to look somewhere else for the referred DLL.
Also you may have a look at MSDN and MSDN2.
Remarks:
Use this setting only at development time. The runtime does not check the versions on
strong-named assemblies found in the DEVPATH. It simply uses the first assembly it finds.
You may have a look to the following articles/webPages, too.
CodeProject - Assembly location, binding, deploying
Social MSDN Questions about DEVPATH
I think this should do the trick!
您应该重建引用这个新 dll 的那些程序集。
You should rebuild those assemblies referencing this new dll.
Windows 事件日志应该提供有关无法加载的内容的更多信息。您是否在新 DLL 中引入了另一个依赖项？我遇到过类似的情况，其中第 3 方 DLL 需要安装 C++ Runtime 2005（大多数开发计算机和大多数桌面上都是这种情况，因为它很常见）。
The Windows EventLog should provide more information about what couldn't be loaded. Did you introduce another dependency in the new DLL? I've encountered something similar, where a 3rd party DLL required the C++ Runtime 2005 to be installed (which is the case on most Dev-machines and also most Desktops, since it is very common).
大胆猜测...您可以检查一下 DLL 所在的文件夹是否标记为只读。
右键单击文件夹>属性> 取消选中只读 >单击“应用”>选择所有子文件夹和文件>好的。
重建您的解决方案。
Wild guess... can you check if the folder where the DLL lives is marked ReadOnly.
Right click on folder > Properties > uncheck ReadOnly > click Apply > choose all subfolders and files > OK.
Rebuild your solution.