Native -> CLI -> Managed dll leading to EEFileLoadException

[DerekSMorin]

I'm hitting the same file load exception in two different scenarios.

1. CppUnitTest calls into mixed cli dll which then attempts to load a custom managed dll in the same folder and fails to load dll with EEFileLoadException.
2. Native console application calls into mixed cli dll which then attempts to load a custom managed dll in the same folder and fails to load dll with EEFileLoadException.

I wasn't sure if any of this was related to
#61105
C++/CLI assembly is loaded into isolated AssemblyLoadContext (IsolatedComponentLoadContext) in .NET 6

I have also tried this in .NET preview 7.

My mixed cli dll is called oqkern.

If I call into it, and then access a standard .net api things work. E.g. something that just works with managed strings or DateTime etc.

But if I call into it and it tries to access stuff from another custom c# dll in the same folder (e.g. Bentley.APM.Settings ) then if fails to load this dll.

Under .NET Preview 7 I am able to start debugging into the assembly binder code and I can see that in BindAssemblyByProbingPaths that pBindingPaths is an empty list.

I'm wondering if what I am trying to do is supported or what the best way for me to achieve my goals is.

I'm not sure if I have to get into something complicated like:
Write a custom .NET host to control the .NET runtime from your native code
https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting

Or if I'm just missing something obvious.

I'll mention @vitek-karas and @elinor-fung as you both seemed very active in the discussions around the c++/cli assembly load context.

Thanks for your time,
Derek

[vitek-karas]

.NET Runtime (as oppose to .NET Framework runtime) does not probe for files on disk. It relies on .deps.json file which is produced by the SDK to determine the list of assemblies it should know about (where to find them). So this means that just copying a .dll next to another one doesn't make it discoverable by the runtime itself.

This is further complicated by the fact that you're loading the runtime from C++/CLI first. In .NET 6 the default behavior is to load only the core frameworks into the default load context, the C++/CLI assembly and all of its non-framework dependencies are loaded into a secondary load context. So in this case the default load context can only resolve assemblies from the framework (So basically System.* and nothing else).

In .NET 7 we changed this default and in this case the C++/CLI is loaded into the default load context which means that the default context will be able to resolve all of framework, the C++/CLI assembly and its dependencies. The dependencies of the C++/CLI assembly are determined by loading the .deps.json file next to it.

So if the assembly you're trying to load was not part of the component during build (typically either ProjectReference or PackageReference) then the runtime will not resolve it.

You can customize this via several different callbacks the runtime provides, the most typical for the default load context would be to add an event handler to the AssemblyLoadContext.Default.Resolving event. Here you can implement for example the policy to look for the assembly file next to the main dll, or whatever other policy makes sense in your case.

Detailed description of the assembly resolution algorithm can be found here: https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/loading-managed (there are other related docs near it in the TOC as well).

[vitek-karas]

@elinor-fung

You can try https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#corehost_trace to get detailed logs from the dependency resolution (assuming it's due to the .deps.json file).
Where do you want to load the dependencies from, if they're not in the bin folder?

[lvde0]

Ideally, they would be loaded from the nuget packages folder/cache. At least this is how C#/managed projects usually behave.

To clarify my scenario I created a small repro here:
Sandbox.zip

[vitek-karas]

Ever since .NET 6 managed projects don't load dependencies from nuget cache - the default is to copy all dependencies into the apps directory (including nuget dependencies). Before .NET 6 the only way we made the nuget cache work was through .runtimeconfig.dev.json which would add the nuget cache to the probing paths. This only works on the machine where the project was built, and that was causing problems, so we removed that.

The case on C++/CLI is a bit more complicated as it may be loaded into a process which doesn't .NET in it yet - so those should carry their dependencies next to them for sure.

[lvde0]

Okay, I managed to get it working now by forcing the package artifacts to be copied to the output folder via <CopyLocalLockFileAssemblies>

[vitek-karas]

Glad to hear that it works for you. Alternatively, you may use https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#enabledynamicloading which is a superset and might be a better fit for this case.