Any way to revert to pre-7.0 isolated assembly loading in C++/CLI?

[mikeoliphant]

I have a framework using C++/CLI to load managed plugins within a native application.

This change to loading assemblies in the default ALC:

#66486

has broken my ability to load multiple plugins.

Is there any way to revert to the previous isolated assembly loading behavior?

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[mikeoliphant]

To add a bit more information, what I have is:

• A native application host that loads native dll plugins (a VST3 audio plugin host, to be specific).
• Managed plugins wrapped in a C++/CLI wrapper framework to act as the native interface with the native host.

So, a "plugin" consists of a folder with the C++/CLI wrapper dll which loads the actual managed plugin code.

I can load a single plugin just fine. I can also load the same plugin multiple times from the same folder. Trying to load a second, different plugin, or even the same plugin, but from a different folder, no longer works (it does in .NET 6.0).

[AaronRobinsonMSFT]

@mikeoliphant There is no current way to revert to the previous C++/CLI behavior.

It would be helpful to get a trace - see instructions here.

/cc @elinor-fung

[mikeoliphant]

Here is a trace:

vsthost.exe_20240705_181811.zip

The application activity was:

• load a plugin
• load the same plugin again from the same location
• load the same plugin again, but from a different path

When the plugin is loaded from a different path, everything goes haywire and the trace keeps getting bigger and bigger. The one I linked above I cut off quickly to keep it from getting too big.

From looking at it with perfview (my first time with the tool, so I don't really know what I'm doing) it looks like it is loading the assembly "AudioPlugSharpVst" over and over again. That assembly is my C++/CLI assembly which is the entry point from the native code.

[AaronRobinsonMSFT]

@mikeoliphant Yep, I see the behavior you are referring to. The solution here is to have a different C++/CLI assembly. We changed this behavior as it more aligned with the majority of C++/CLI use cases coming from .NET Framework. Is it possible for you to adapt to the new behavior?

[mikeoliphant]

This is my github repo:

https://github.com/mikeoliphant/AudioPlugSharp

The C++/CLI assembly is a framework for loading managed plugins from native code (specifically, VST3 audio plugins).

If I'm understanding you correctly, I don't see how it would work for me to have different C++/CLI assemblies per plugin.

[AaronRobinsonMSFT]

Oh, I see. You provide a single C++/CLI assembly and anyone can drop that next to their plug-in written in .NET and it will get loaded, right?

[mikeoliphant]

Oh, I see. You provide a single C++/CLI assembly and anyone can drop that next to their plug-in written in .NET and it will get loaded, right?

Yep, that's exactly it.

[AaronRobinsonMSFT]

I see. This is going to require feedback from @elinor-fung. My gut tells me this isn't something we are likely to add support for, but I'll defer to the hosting experts.

[mikeoliphant]

My gut tells me this isn't something we are likely to add support for, but I'll defer to the hosting experts.

If so, that would be very disappointing if I have no possible way to work around it.

Can you give me some insight as to why it isn't working? My code should work in both the case that the separate instances of the C++/CLI assembly are loaded independently and isolated, and also in the case that only one copy is loaded and used.