title: could not load file or assembly exception NET 5/6 of NuGet package for NET Standard
body: <p>I'm at the end of my rope trying to figure out why my working DLL cannot load a NuGet package that it could always load before (like for a whole year). My system has 70 NET 6 projects and half a dozen of them use the same NuGet package to read XML files. Recently (a few months ago) I upgraded everything to NET 6, and even after that upgrade, everything worked fine.</p>
  <p>But now, one of my C# class libraries generates an exception in a constructor because it can't find the NuGet package that sits right beside it in the filesystem app folder where everything is loaded from. The error message was:</p>
  <pre><code>.ctor Could not load file or assembly xxx blah blah. The system could not find the file specified.
  </code></pre>
  <p>For what it is worth, here is a trace of the build options in the batch file that I have been using for months.</p>
  <blockquote>
  <p>Deleting hscore\hscore\bin Deleting hscore\hscore\obj Deleting
  hscore\hscore\packages &quot;C:\Program Files\Microsoft Visual
  Studio\2022\Community\MSBuild\Current\Bin\msbuild.exe&quot; -nologo -m
  -V:minimal -t:clean;restore;publish /p:Platform=AnyCPU /p:PlatformTarget=AnyCPU /p:Configuration=Debug
  /p:TargetFramework=net6.0-windows7.0  /p:RuntimeIdentifier=win-x64
  /p:SelfContained=false /p:PublishProtcol=FileSystem
  /p:DeleteExistingFiles=true /p:PublishDir=c:\dev\holding\core.plt
  -nowarn:MSB3305 c:\dev\products\hscore\hscore\hscore.csproj</p>
  <p>Determining projects to restore...   Restored
  c:\dev\products\hscore\hscore\hscore.csproj (in 874 ms).
  hscore -&gt; c:\dev\products\hscore\hscore\bin\Debug\net6.0-windows7.0\win-x64\hscore.dll
  hscore -&gt; c:\dev\holding\core.plt\</p>
  </blockquote>
  <p>I have done the following to debug it, without success:</p>
  <ul>
  <li><p>deleted the bin/obj folders of the failing class library</p>
  </li>
  <li><p>checked the target framework of all projects (= net6.0-windows7.0)</p>
  </li>
  <li><p>checked the runtime identifier of all projects (= win-x64)</p>
  </li>
  <li><p>checked the build configuration (Debug, AnyCPU)</p>
  </li>
  <li><p>removed and re-added the NuGet package (with a specific version)</p>
  </li>
  <li><p>the Nuget package depends on NET Standard, compatible with NET 6</p>
  </li>
  <li><p>and I use the same version in other NET 6 programs that are working fine</p>
  </li>
  <li><p>restored and rebuilt the DLL</p>
  </li>
  <li><p>published it to the destination folder where it is run from</p>
  </li>
  <li><p>checked that the expected Nuget package is there (it was)</p>
  </li>
  <li><p>and yet it still fails to find the Nuget package</p>
  </li>
  <li><p>I tried to trace DLL loads of the process with the SysInternals Process Monitor, but I am not good enough to do that (if it is even possible). I can filter events to see the parent app process load, but the failing DLL is called by the parent process and I don't know how to see the search paths it is using to find the Nuget package.</p>
  </li>
  </ul>
  <p>I want to believe that the problem is a version mismatch between NET 5 and NET 6 and the version of the Nuget package sitting in the folder, because I once had a problem like that. For example, if I had a NET Framework version of the Nuget package, it would not be &quot;found&quot; by a NET 5 DLL that wanted to load it. (I am NOT saying that is my problem, because I have no NET Framework projects anymore.)</p>
  <p>The most recent thing I have been working on is the build system and options. I can build the whole system with batch files or with parallel builds (when the system is working). I use the same msbuild options in both cases, and the batch method has been reliable and shows no build errors, no publish errors, all the correct build options, and no warnings or errors whatsoever.</p>
  <p>The Nuget package pulls in 10 or 20 dependencies, but that is all automatic, and the package works with other console programs and apps that are working fine. So, I don't think there is anything wrong with Nuget package. All the working apps use the same Nuget package from the same runtime folder. I don't know why this one DLL is having a problem. AND I have not changed anything in the failing DLL class library for months (and it has been working fine).</p>
  <p>Does anyone have suggestions on what else I might try to debug the problem and get the system working again? Thank you.</p>
  <p>UPDATE - New version and build, but still a runtime failure.</p>
  <p>Just to be sure, I upgraded the Nuget package that could not be found to the latest version and replaced all references in my 70 projects to the new version. Then I rebuilt the system (no warnings, no errors). But that did not make a difference. Now the new version cannot be found.</p>
  <p>All unit tests of the code in question work flawlessly in VStudio, presumably because VS loads the Nuget package properly. I am mystified and would appreciate thoughts on how to proceed. Thank you.</p>
  <p>UPDATE 2 - installed 'dotnet-trace' and traced DLL loads</p>
  <p>I found a page that described how to <code>dotnet tool install --global dotnet-trace</code> and then captured a trace of my app trying to find the elusive Nuget package that is sitting right beside the requesting DLL. Although I could my app loading various app DLLs (and tons of system DLLs) with found pathnames, the trace showed nothing useful about the Nuget package.</p>
  <p>The trace entries show the system searching in stages FindInLoadContext, then ApplicationAssemblies, then AppDomainAssemblyResolveEvent. After that, the system throws an exception because it can't find the Nuget package.</p>
  <p>I would have thought the system FindInLoadContext would find it in the same folder as the executing and requesting assemblies, but it seems not so.</p>
  <p>Ideas? I'm lost. And everything used to work fine.</p>
  <p>UPDATE 3 - A small console app calls the DLL and it finds the Nuget package</p>
  <p>The problem scenario in this question is: WindowsFormsApp -&gt; loads MyCore.dll and calls <code>new MyCore.MyObject()</code>, which in the constructor tries to read some XML files using MyUtils.dll, which tries to reference the mystery Nuget package for reading XML files. MyUtils.dll cannot find the package, no matter what I do.</p>
  <p>I wrote a small console program to load MyUtils.dll and called the exact same <code>MyUtils.ReadMyXmlFiles</code> API to read the files. The console app (actually, the system assembly loader) correctly found the Nuget package and read the XML files properly. This all occurred in the same folder that contains the Forms app and the Nuget package.</p>
  <p>The only difference now is that the WindowsForms app calls an intermediate DLL that calls a constructor that references MyUtils.dll.</p>
  <p>Could the intermediate DLL + constructor call be changing the Assembly Load Context (FindInLoadContext search rules) for the Nuget package load operation? Very strange.</p>