[Bug] Can't resolve dependencies when using C++/CLI Assemblies

[electro-logic]

When launching

dscom tlbexport my.dll --asmpath D:\mypath

I found an unhandled exception with Visual Visual Studio:

Exception thrown at 0x00007FFB7531831A in dscom.exe: Microsoft C++ exception: HRMsgException at memory location 0x00000000001C7380.

at the function LoadFromAssemblyPath(dllToLoad)

dscom/src/dscom.client/AssemblyResolver.cs

Line 48 in 14dad8d

return LoadFromAssemblyPath(dllToLoad);

and the issue is that not all types are loaded.

By replacing LoadFromAssemblyPath() with

Assembly.LoadFile(dllToLoad)

the assembly and all dependencies are correctly loaded.

Additional details:

my.dll is defining a COM interface and a class derived from MyLib.MyClass that is a class in another assembly that actually implement the interface

    [ComVisible(true)]
    [InterfaceType(ComInterfaceType.InterfaceIsDual)]
    [Guid("AA3C9EF2-AAAA-424B-8A96-35910B102956")]
    public interface ISum
    {
        int Sum(int a, int b);
    }

    [ComVisible(true)]
    [ClassInterface(ClassInterfaceType.None)]
    [Guid("AAAB3576-AAAA-4652-A87A-3579DD85AF69")]
    public class ComSum : MyLib.MyClass, ISum
    {
        
    }

[carstencodes]

Replacing LoadFromAssemblyPath with Assembly.LoadFile would make the loaded assemblies no longer be collectable, as these collected assemblies are now part of the global context.

I am currently wondering, if this issue might be related to [asmPaths = asmPaths.Prepend(dir).ToArray();](https://github.com/dspace-group/dscom/blob/14dad8d8c1fd75d996e00b2d2af949a9c2623cc5/src/dscom.client/AssemblyResolver.cs#L40).

Is MyLib.MyClass located in an assembly next to my.dll or in D:\mypath?

[electro-logic]

All .dll are located in the same D:\mypath folder.
The variable dllToLoad is pointing to the right file when calling LoadFromAssemblyPath(), but for some reasons seems the wrong API to call.
I haven't deeply investigated, but Assembly.LoadFile() is working.

[carstencodes]

Anything special about your MyLib.dll (.NET Fx or ComImports)?

I have tried to reproduce the issue locally, but somehow it seems to work for me?

[electro-logic]

MyLib (that contains MyClass) is a C++/CLI .DLL
The issue is related to dotnet/sdk#44168

[carstencodes]

Ah, ok. Is this a .NET 6/7/8/9 DLL assembly or is it a dotnet fullframework C++/CLI DLL? Which dependencies are involved, i.e. C++ DLLs next to the assembly?

If so, we just "forgot" to attach the DllImportResolver in the LoadContext

[carstencodes]

Is it any special or can you provide me the input assemblies?

[carstencodes]

@electro-logic here is my patch for this:

internal sealed class AssemblyResolver : AssemblyLoadContext, IDisposable
{
    private bool _disposedValue;
    private readonly List<AssemblyName> handledNames = new List<AssemblyName>();

    internal AssemblyResolver(TypeLibConverterOptions options) : base("dscom", isCollectible: true)
    {
        Options = options;
        Resolving += Context_Resolving;
        ResolvingUnmanagedDll += Context_ResolvingUnmanagedDll;
    }

    private IntPtr Context_ResolvingUnmanagedDll(Assembly assembly, string dllName)
    {
        var name = assembly.GetName();
        if (!this.handledNames.Contains(name))
        {
            return IntPtr.Zero;
        }

        string[] validNativeImageExtensions = new[] {".dll", ".exe"};
        var loadPaths = GetLoadPaths();

        foreach (var loadPath in loadPaths)
        {
            foreach (var extension in validNativeImageExtensions)
            {
                string nativeImageFile = Path.Combine(loadPath, dllName + extension);
                if (File.Exists(nativeImageFile))
                {
                    return LoadUnmanagedDllFromPath(nativeImageFile);
                }
            }
        }

        return IntPtr.Zero;
    }

    private Assembly? Context_Resolving(AssemblyLoadContext context, AssemblyName name)
    {
        handledNames.Add(name);
        var assemblyPaths = GetLoadPaths();

        foreach (var path in assemblyPaths)
        {
            var dllToLoad = Path.Combine(path, $"{name.Name}.dll");
            if (File.Exists(dllToLoad))
            {
                return LoadFromAssemblyPath(dllToLoad);
            }

            var exeToLoad = Path.Combine(path, $"{name.Name}.exe");
            if (File.Exists(exeToLoad))
            {
                return LoadFromAssemblyPath(exeToLoad);
            }
        }

        return null;
    }

    public Assembly LoadAssembly(string path)
    {
        return LoadFromAssemblyPath(path);
    }

    public TypeLibConverterOptions Options { get; }

    private void Dispose(bool disposing)
    {
        if (!_disposedValue)
        {
            if (disposing)
            {
                Resolving -= Context_Resolving;
                Unload();
            }

            _disposedValue = true;
        }
    }

    public void Dispose()
    {
        Dispose(disposing: true);
        GC.SuppressFinalize(this);
    }

    private IReadOnlyCollection<string> GetLoadPaths()
    {
        var dir = Path.GetDirectoryName(Options.Assembly);

        if ((dir != null) && !Path.IsPathRooted(dir))
        {
            var fullDir = Path.GetFullPath(dir);
            if (fullDir != null)
            {
                dir = fullDir;
            }
        }

        var asmPaths = Options.ASMPath;
        var assemblyPaths = new List<string>(asmPaths);
        if (Directory.Exists(dir))
        {
            assemblyPaths.Insert(0, dir);
        }

        for (int i = 0; i < assemblyPaths.Count; i++)
        {
            var path = assemblyPaths[i];
            if (!Path.IsPathRooted(path))
            {
                var relPathToDir = Path.Combine(dir, path);
                var relPathToCurrent = Path.Combine(Directory.GetCurrentDirectory(), path);

                if (Directory.Exists(relPathToDir))
                {
                    assemblyPaths[i] = relPathToDir;
                }
                else if (Directory.Exists(relPathToCurrent))
                {
                    assemblyPaths[i] = relPathToCurrent;
                }
            }
        }

        return assemblyPaths;
    }
}

Does this work for you?

[electro-logic]

Here a demo (both projects .NET 9 32 bit) to reproduce the issue:

BugDemo.zip

dscom (non patched) is emitting a warning

dscom : warning TX00000000 : Type library exporter encountered an error while processing 'CsLibrary'. Error: Could not load file or assembly 'CppLibrary, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.

and the resulting .tlb file is missing the type.
C++/CLI is actually making CLR assemblies as output (same as C#), so I'm not sure DllImportResolver is related to this issue. For sure helps to load native dependencies so can be worth to keep it.

[carstencodes]

Ok, here we seem to have found an issue:

With C++/CLI Images, we might have another issue found in AssemblyLoadContext:

This is currently limited by the dotnet runtime itself.

I'll check back with @marklechtermann @matthiasnissen and @SOsterbrink what the original issue was why the assembly load context was chosen to be collectible.

[electro-logic]

Yes, collectible assemblies seems to be not COM-friends
https://learn.microsoft.com/en-us/dotnet/fundamentals/reflection/collectible-assemblies#restrictions-on-collectible-assemblies