NET 5 DLL 存在但未加载
这个问题是关于为什么程序集找不到驻留在同一文件夹中的库。据我所知，调用者的位数（x64）与无法找到的NuGet包（AnyCPU）一致。
即使我将所有内容重新编译为 AnyCPU，错误消息仍然存在：
Could not load file or assembly 'ChoETL.Core, Version=1.2.1.28, etc.' The system cannot find the file specified.
我发布的 NET 5 exe (x64) 文件调用已发布的 NET 5 库，该库在错误消息中调用 Nuget 包 ChoETL.Core (exe- >lib->ChoETL.Core)。
这是我用来构建程序 exe 和中间库 .csproj 文件的命令行。我不使用 Visual Studio，也不使用解决方案 .sln 文件。所有文件构建时都不会出现错误或警告。
msbuild -t:restore;publish /p:Platform=x64 /p:PlatformTarget=x64 /p:Configuration=Debug /p:TargetFramework=net5.0-windows7.0 /p:RuntimeIdentifier=win-x64 /p:PublishDir=c:\dev\holding\core.plt xxx.csproj
以下是库的 .csproj 文件中引用 ChoETL.Core 包的引用。请记住，msbuild 命令行属性会覆盖下面 csproj 文件中的 AnyCPU 值。
<PropertyGroup>
<UseWindowsForms>true</UseWindowsForms>
<Platforms>AnyCPU</Platforms>
<PlatformTarget>AnyCPU</PlatformTarget>
<TargetFramework>net5.0-windows7.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="ChoETL" Version="1.2.1.28" />
</ItemGroup>
我认为 CorFlags 值可能是问题所在，所以我检查了它们。如下（32bitreq/prefs 为零）：
Program.exe: PE32+, flags 0x9, ILONLY 1, Signed 1
Library.dll: PE32+, flags 0x9, ILONLY 1, Signed 1
ChoETL.Core: PE32, flags 0x1, ILONLY 1, Signed 0
PE32+ 表示 x64，PE32 表示 AnyCPU（如果程序集加载到 64 进程中，则它作为 64 位程序集运行）。所以，它们应该是兼容的（此外，我无法编译 NuGet 包）。
我看了这个SO问题，但没有帮助。 无法加载文件或程序集，系统找不到指定的文件
有谁知道当所有三个程序集并排在同一文件夹中时为什么库找不到 ChoETL.Core.dll 库？ 我花了好几天的时间来解决这个问题，但没有任何进展或成功。谢谢。
This question is about why an assembly cannot find a library that resides in the same folder. As far as I can tell, the bitness of the caller (x64) agrees with the unfindable NuGet package (AnyCPU).
Even when I recompile everything to AnyCPU, the error message remains:
Could not load file or assembly 'ChoETL.Core, Version=1.2.1.28, etc.' The system cannot find the file specified.
My published NET 5 exe (x64) file calls a published NET 5 library that calls the Nuget package ChoETL.Core in the error message (exe->lib->ChoETL.Core).
Here is the command line that I used to build the program exe and intermediate library .csproj files. I do not use Visual Studio and do not use the solution .sln file. All files build without errors or warnings.
msbuild -t:restore;publish /p:Platform=x64 /p:PlatformTarget=x64 /p:Configuration=Debug /p:TargetFramework=net5.0-windows7.0 /p:RuntimeIdentifier=win-x64 /p:PublishDir=c:\dev\holding\core.plt xxx.csproj
Here is the reference in the .csproj file of the library that references the ChoETL.Core package. Keep in mind that the msbuild command line properties override the AnyCPU values in the csproj file below.
<PropertyGroup>
<UseWindowsForms>true</UseWindowsForms>
<Platforms>AnyCPU</Platforms>
<PlatformTarget>AnyCPU</PlatformTarget>
<TargetFramework>net5.0-windows7.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="ChoETL" Version="1.2.1.28" />
</ItemGroup>
I thought maybe the CorFlags values might be the issue, so I checked them. There were as follows (32bitreq/prefs were zero):
Program.exe: PE32+, flags 0x9, ILONLY 1, Signed 1
Library.dll: PE32+, flags 0x9, ILONLY 1, Signed 1
ChoETL.Core: PE32, flags 0x1, ILONLY 1, Signed 0
PE32+ means x64, and PE32 means AnyCPU (if the assembly is loaded into a 64 process, it runs as a 64-bit assembly). So, they should be compatible (and besides, I cannot compile the NuGet package).
I looked at this SO question, but it did not help.
Could not load file or assembly, system could not find the file specified
Does anyone have any idea why the library cannot find the ChoETL.Core.dll library when all three assemblies are side by side in the same folder?
I've spent days on the problem without progress or success. Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
经过一天的调试，我的工作正常了，但我不知道到底为什么。我从一个简单的控制台程序开始，然后是 exe + lib，然后是 exe + lib（称为 ChoETL），最后用我的真实系统的一部分制作了一个测试用例。当我开始对真实系统的一部分进行实验时，一切都工作正常。但我想，它很脆弱。
这里有一些可能对下一个人有帮助的理论。
一个关键问题（在发生故障的实际系统中）是
msbuild ... -t:clean;restore;publish操作未发布 ChoETL 包。我认为这是问题的一个主要部分。然而，当我使用相同的 msbuild 命令行构建测试实验时，ChoETL 始终在使用该包的可执行文件和库旁边正确发布。当时，我认识到我的实验总是在开始新构建之前完全删除 bin 和 obj 文件夹，而我真正的系统构建文件并没有采取那么激烈的操作（认为 msbuild clean/restore 对于干净构建来说就足够了） 。但是，事实并非如此。 Msbuild 没那么聪明。我修改了我的真实系统构建文件，以在构建开始时完全删除 70 个项目构建序列中的所有 obj/bin 文件夹，并且 ChoETL 已正确发布在使用它的程序集旁边。
最后，原来的问题得到了解决（但并没有真正理解）。系统可以找到 ChoETL 并加载它。我所知道的是，在开始时完全删除 obj 和 bin 文件夹可以使构建成功。我不清楚 obj/bin 文件夹中的哪些文件或数据元素可能会阻止成功的发布操作。也许是
project.assets.json文件，或者可能是其他 json 文件之一。我确实知道当 csproj 文件和 msbuild 命令行属性更改时，msbuild 不容易重新生成 json 文件。由于此类问题，自从开始使用 NET 5 的几个月以来，我已经养成了完全删除 obj/bin 文件夹的习惯。
我认为 msbuild 会像 make 一样进行依赖性和时间戳分析，并在 json 文件“过时”时重新生成它们（无论这在这种情况下意味着什么；我不知道）。但事实并非如此。因此我开始养成在构建之前完全删除 obj/bin 文件夹的习惯。显然，这次经历（几周的发展延迟）表明，我还有很长的路要走，才能将其养成严格的习惯。我希望这个答案可以帮助其他人。
After yet another day of debugging, I have things working, but I don't know exactly why. I started with a simple console program, then exe + lib, then exe + lib (that called ChoETL), and finally made a test case with part of my real system. By the time I got to experiments with part of the real system, things were working okay. But fragile, I imagine.
Here are some theories that might help the next person.
One key issue (in the real system that was failing) was that the ChoETL package was not being published by the
msbuild ... -t:clean;restore;publishoperation. I think this was a major part of the problem. Yet, as I built up my test experiments using the same msbuild command lines, ChoETL was always being published correctly beside the executables and libraries that consumed the package.At that time, I recognized that my experiments always completely deleted the bin and obj folders before starting a new build, whereas my real system build files did not take that drastic action (thinking that msbuild clean/restore would be sufficient for a clean build). But, not so. Msbuild is not that smart. I modified my real-system build files to completely delete all obj/bin folders in the 70-project build sequence at the start of the build, and ChoETL was correctly published beside the assemblies that consumed it.
And at last, the original problem was solved (but not really understood). The system could find ChoETL and load it. All I know is that completely deleting the obj and bin folders at the start enabled a successful build. I do not have a clear idea of what file(s) or data elements in the obj/bin folders might have prevented a successful publish operation. Maybe it was the
project.assets.jsonfile, or maybe it was one of the other json files.I do know that msbuild does not easily regenerate the json files when csproj files and msbuild command line properties are changed. I have developed the habit of completely deleting the obj/bin folders in the months since starting to work with NET 5 because of such problems.
I thought msbuild would do dependency and timestamp analysis like make does, and regenerate the json files if they were "out of date" (whatever that might mean in this context; I don't know). But it does not. Thus I have started to develop the habit of completely deleting the obj/bin folders before a build. Obviously, this experience (a development delay of weeks) shows that I still have much further to go with developing that into a rigid habit. I hope this answer might help someone else.