COM Interop / DotNetInvokerServer potential behavior change

We have fixed an issue with DotNetInvokerServer failing to resolve necessary DLL dependencies. Previously it calls .NET Assembly library's LoadFile which loads the specified assembly, but this method does not resolve dependencies. This means custom COM code that references an external library will not work properly or silently fail.

This has been resolved by calling LoadFrom() instead, which attempts to automatically resolve dependencies, for example it will attempt to search for dependencies in the same folder and load them. However, in rare cases the dependency may resolve to an already loaded version with the same identity but on a different path, which might potentially be an issue in development environments. Please perform a smoke test with your COM interop functionalities to ensure they are working fine.