Type activation requires assemblies to be next to the exe

[stevenbrix]

This breaks users who use a DllImport to load a WinUI assembly, as this will cause them to be loaded from the Runtime Identifier specific directory. What this means is that we'll have two different versions of the WinUI assemblies loaded in the process.

We should fix type activation so that it can look in the RID-specific folders.

This also breaks Runtime-Independent apps (AnyCPU) that need to bundle all their native dependencies with them. While this scenario may be considered out-of-scope for WinUI3, the fact that DllImport causes different assemblies to be loaded seems like an issue we need to address by WinUI3 RTM.

I think the current behavior is ok as-is for Preview1.

[stevenbrix]

Adding this comment so this doesn't get lost...

I ran into the following issue a while back when doing some prototyping early on of WinUI3 in .NET5: dotnet/sdk#765

Once we address this type activation issue, we'll no longer be manually copying files into the output of the app, so we'll hit this issue in Xaml Islands apps where a WPF app does not directly reference the WinUI Nuget.

[Scottj1s]

@jkoritzinsky, is there an API for querying RID? Something DllImport uses under the hood, that we could also use in probing for implementation DLLs?

[jkoritzinsky]

The RID information is in the application's .deps.json file. There isn't really a good way to hook into it.

If we try to load native libraries for activation on .NET 5 via the NativeLibrary.Load method that takes an Assembly instance, it should use the same lookup paths as DllImport.