Support preview for dll project

[roxk]

1. Detect dll vs exe project
2. For dll project, use the previous injected non-packaged app approach. Make the dummy app project depends on dll project
3. If its dll project launch the dummy app

---

Try this first before the above:

1. Bundle unpackaged self-contained preview app
2. Pass dll path to app
3. LoadLibrary
4. Make sure down stream library work

If (4) doesn't work has to fallback to above method. Also want to prevent nuget getting too large

[roxk]

Confirmed (4) works. The problem is whether
(a) we can list all dll a project is using in the extension, and
(b) reliably move the preview app to the dll folder path

(b) is a problem since there might be name collision, the dll also somehow specified selfcontained == true, etc. But in theory it is working.

The whole self contained preview app is also 60MB. Zipped 20MB. Not bad for a nuget, but not ideal either, but it's an inherent limitation of WinUI 3. Framework-dependent deployment is possible but that can complicate the setup.

[roxk]

Tested some more of non-winrt dll. Finding:

1. A dll project A linking another Non-WinRT dll B require LoadLibrary dll B first
2. Non-WinRT DLL is working, provided that the extension can find the dll path (i.e. dll B in (1))
3. Also tested winrt dll ordering: the order doesn't matter. As long as at call site (i.e. winrt::activate_instance) the dll is loaded order doesn't matter.

[roxk]

Several details breaking things:

1. Lib are shipped with xbf not xaml, so generic.xaml handling can't simply read the xaml. Must use resource dict Source(Uri), and work out a ms-appx:// path for the lib It is wrong. Xaml runtime would load it automatically. I was testing it without the files next to the app.
2. nuget dependency needs to be taken into account, by checking Reference whose filename ends in .winmd and there is an Implementation

• Use ms-appx:// to handle themes/generic No need to handle...The XAML runtime loads it automatically
• Load metadata provider on demand, so that nuget dependency is handled automagically
• Make LoadLibrary look up dll's dependency
• Do not loadLibrary every time for the same preview app (in the same project)
• Only extract preview app for dll project
• Handle CsWinRT component Blocked

[roxk]

CsWinRT decides xaml metadata info should be in a separate namespace...

[roxk]

Note to self: now that cswinrt dll support PoC has been completed, it's clear that the alternative approach of building an app referencing the dll project isn't as robust as the standalone preview app approach (i.e. current main at 1fbca24). This is because building an app that reference cswinrt component requires reg-free activation via fusion manifest or package manifest.

[roxk]

All of this complexity could be removed by allowing user to express that "previewing of this dll project should launch another app project"...

[roxk]

Ok so winrt dll's winrt dependency's asset folder aren't copied to the dll's output dir by default...

Update: Debug would copy, but release wouldn't....what.

[roxk]

Using Private on WinRT dll project would copy the output to referencing project, but wouldn't on ordinary dll...

[roxk]

Adding private doesn't make a dll dependency's nuget getting copied to referencing project 🥲 Looks like there is no built-in solution that works.

• Try to see if it's possible to gather project reference -> copy all project's output dir's stuff to preview folder

[roxk]

Current situation: Dynamically loading WinRT.Host.dll for some reason always trigger crash, thanks to microsoft/CsWinRT#623. Current impl simply try WinRT.Host.dll if a provider can't be found from the loaded dll (i.e. try to see if its CsWinRT component if loading as CppWinRT component failed. It's as if you can only activate class from WinRT.Host.dll once

Argh.

[roxk]

CsWinRT dll support would have to be halted for now due to microsoft/CsWinRT#1564.

[roxk]

Given the hacky nature of dynamic WinRT component direct mode support, I'd advice developers simply use sample app mode. Direct mode would remain supported for quirk-and-dirty scenario, but might be removed completely in the future.