Issues using WinUI with winrt-rs

[joekgh]

I am attempting to use a WinUI control via Xaml Islands and winrt-rs. I can get the windows::ui::xaml::controls to work however I ran into a number of issues with microsoft::ui::xaml::controls.

1. The dll from Microsoft.UI.Xaml does not get copied to target/debug automatically by cargo winrt install. It is downloaded to target/nuget/Microsoft.UI.Xaml/win10-x64/. Dlls from other NuGet packages do get copied as expected. I manually copied it to move forward.
2. The Microsoft.UI.Xaml.dll depends on Microsoft.VCRTForwarders.140 dlls. This results in the same error, HRESULT 0x80040154 I received before I copied Microsoft.UI.Xaml.dll. I am not sure if cargo winrt can detect this situation and provide the user with additional feedback because it was very confusing at first. I added the VCRTForwarders to [package.metadata.winrt.dependencies]. The dlls were downloaded into target/nuget/Microsfot.VCRTForwarders.140 but not were not copied to target/debug. I manually copied them to move forward.
3. At this point my sample will compile and run, however, I get an STATUS_ACCESS_VIOLATION when I try to create a WinUI control, NumberBox in this case (see an example here).

I could not create a concise example to share since all of the Xaml Islands setup needs to be done before I encountered the issue in step 3. I have pushed a full repo to show the issue: https://github.com/joekgh/win_ui

Some other notes:

• The error message cargo winrt generates for a missing dll is the same as the error for a missing NuGet package

Compiling bindings v0.1.0 (C:\Users\joe\workspace\win_ui\bindings)
error: could not read dependency: dependency path 'C:\Users\joe\workspace\win_ui\target\nuget\Microsoft.UI.Xaml' does not exist

• cargo winrt does not generate any output while it is running. It is hard to know what happened (especially if something goes wrong). Visual Studio NuGet Package Manager outputs quite a bit of status:

Attempting to gather dependency information for package 'Microsoft.UI.Xaml.2.5.0-prerelease.200609001' with respect to project 'WinUICpp', targeting 'native,Version=v0.0'
Gathering dependency information took 80 ms
Attempting to resolve dependencies for package 'Microsoft.UI.Xaml.2.5.0-prerelease.200609001' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.UI.Xaml.2.5.0-prerelease.200609001'
Resolved actions to install package 'Microsoft.UI.Xaml.2.5.0-prerelease.200609001'
Adding package 'Microsoft.UI.Xaml.2.5.0-prerelease.200609001' to folder 'C:\Users\joe\workspace\WinUICpp\packages'
Added package 'Microsoft.UI.Xaml.2.5.0-prerelease.200609001' to folder 'C:\Users\joe\workspace\WinUICpp\packages'
Added package 'Microsoft.UI.Xaml.2.5.0-prerelease.200609001' to 'packages.config'
Successfully installed 'Microsoft.UI.Xaml 2.5.0-prerelease.200609001' to WinUICpp
Executing nuget actions took 2.16 sec
Time Elapsed: 00:00:02.6648443

Special thanks to @roblabla and their ubuntu-installer which I copied ideas from liberally.

Thanks in advance.

[kennykerr]

Hi Joe, thanks for reaching out.

Regarding (1) I can confirm that the DLL is not copied automatically by cargo winrt. Also, thanks for the feedback on cargo winrt usability! @rylev can you investigate?

Regarding (2) I'm not sure how we'd detect such a dependency. Note that the VCRTForwarders should only be used for compat with legacy DLLs originally designed for store apps. WinUI should not depend on these. @jevansaks from the WinUI team to comment. Hopefully WinUI 3 has no such dependency and simply uses the standard static CRT to avoid dependency hell.

There are a few known issues with type system support in winrt-rs that I'm working on right now that will be needed to support all Xaml-style composable WinRT types. I should have all of the type system issues ironed out in a week or two. Note that full Xaml support requires the ability to implement and derive from existing WinRT types and that's still going to be a while but I am working on it. #81

[joekgh]

Kenny, thanks for the quick feedback.

For (2), I only figured out why Microsoft.UI.Xaml.dll wasn't loading by using procmon to see what paths were being looked for. I originally found the missing dlls in:
c:\Program Files\WindowsApps\Microsoft.VCLibs.140.00.Debug_14.0.27810.0_x64__8wekyb3d8bbwe
Later I was reading this and saw the section "Handling Dependencies" which mentioned VCRTForwarders. I guess that is a long way of saying that I didn't choose to go this path, I kind of backed into it.

I am eagerly waiting for #81 as there are some other ideas I want to try that depend on it.

[jevansaks]

We are actively discussing how to handle the CRT linkage for WinUI 3.0. Static is convenient, but is dll bloat. For now the VCRTForwarders nuget package approach is the right solution for unpackaged apps.

I don't know enough about the cargo packaging to say why the dll isn't copied forward.

The crash at runtime is likely because you are missing resources for your app. In particular MRT is looking to load resources from a resources.pri near the app. Again, the use of MRT in unpackaged apps is something we're also discussing how to address for WinUI 3.0.

Is packaging the app a possibility for this experiment? The Windows Application Packaging project in VS might be usable here -- unless we're trying to avoid VS tools entirely?

[kennykerr]

The VCRT Forwarders is a workaround until the VC team fix their libs. Which CRT you use is up to you, but the point here is that this dependency is opaque to developers that don't happen to be writing a C# app or the very few C++ apps using msbuild, which can presumably figure this out. Increasingly, developers are building apps for Windows using something other than Visual Studio and msbuild. They are already having to download the WinUI nuget package as a zip file and extract the dependencies, but reverse-engineering msbuild itself is a bit much. If components can simply include their dependencies (e.g. whatever CRT you choose) then projects can simply consume WinRT components like WinUI, whether that project is using cmake or cargo or something else entirely.

[kennykerr]

Issues on the winrt-rs side should now all be addressed. Let us know if you have any more issues.