WinUI 3 link to 3rd party dll that depends on Microsoft Visual C++ 2015 Redistributables

[jeffdod]

Hello, I'm working on a WinUI 3 packaged app. There are a couple of 3rd-party dll's that I'd like to reference from my app. These dll's were written in C++, and depend on the Microsoft Visual C++ 2015 Redistributables (specifically, the 64-bit (x64) 14.0.24215 version). Here's what I'm finding:

If I reference these dll's from a WinUI 3 application, the application builds and runs. However, when I try to navigate to a button handler that calls code in the dll's, my app crashes with an exception. The exception reads as follows:

Could not load file or assembly 'C:\Projects\LucidDotNet\Main\bin\x64\Debug\net8.0-windows10.0.19041.0\win-x64\AppX\ArenaNET_v142.dll'. The specified module could not be found.

The dll in question is, in fact, present in the directory listed in the above exception message. However, I was wondering if the dll is failing to load due to its dependency on the VC++ runtimes.

I can reference and use these dll's with no issues from something like a .NET 8 WPF application; it's only in a WinUI 3 app that it does not work.

By the way, the method I used to reference the dll's was to right-click on my project's "Dependencies" and add them as file references. They then show up under the "Assemblies" section of the Dependencies. I also tried setting their "Copy Local" properties to "Yes," but that made no difference.

So my question is: Is there something special you have to do in order to package such dll's in a WinUI 3 application that is not necessary to do on a WPF application?

[DarranRowe]

There should be nothing special.
If it is unpackaged, then it would find the VC++ redistributable by referencing the system libraries. If it is packaged then it would be referenced via the usual package dependencies.
However, the BIG BIG BIG thing here is that the path that you provided includes Debug. Is this using the debug runtime? If it isn't, then the most likely thing is that you just need to reference the VC runtime package or install the VC redistributable. This happens by default for C++ applications, as you may imagine, but it seems like not for C#.

What this means is, basically, first check whether or not you need the debug version of the VC runtime. If you don't then you could just get away with just using the release version. If your application is unpackaged, then just install the Visual C++ 2015-2022 redistributable that matches your application's architecture onto the target machine along with your application. If it is packaged, then just edit the project's Package.appxmanifest file, find the section that reads:

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.19041.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.19041.0" />
  </Dependencies>

and just add:

<PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.30704.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />

to it. The entire section should be:

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.19041.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.19041.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.30704.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>

This will reference the latest Visual C++ 2015-2022 redistributable that was packaged up. Hopefully this is good enough to get things going.

If the library does require the debug runtime for debug builds, then things get problematic. The debug runtime isn't seen as redistributable and you would likely need the debug UCRT too. But we'll deal with that if needed.

[jeffdod]

I did verify that the PackageDependency made it across into the Appxmanifest.xml file, but I've still not managed to get this to work. However, I greatly appreciate the assistance and detailed answers!

[lhak]

You might want to check if the dll has any other dependencies (there are multiple tools that can provide this information). I have seen this issue quite often when there is a dependency on another dll that might be installed into a directory references by the PATH environment variable, but is not in the windows folder. In this case, these dlls also have to be added to the application package if you want to run in packaged mode.

[DarranRowe]

Just to give an example that does work.

WinUIPInvoke.zip

This platform invokes into a C++ DLL. The DLL only depends upon the VC Redistributable, and the dependency is properly placed in the manifest. Test it out yourself.

If you are, understandably, sceptical about the native DLLs,

TestDll.zip

This is the C++ DLL project that I used. You can inspect and rebuild them. Just remember to build the Release configuration and copy the files to the C# project directory.

If your particular layout isn't working, then I would recommend Process Monitor to figure out what the application is doing. You can check what files Windows is looking for, so you can use this to discover if there is a dependency that you are unaware of, as @lhak rightfully suggested.

[jeffdod]

I tried the suggestion you both made about tracking dependencies, and here's what I saw:

Arena_v140.dll
MSVCP140.dll
GCBase_MD_VC140_v3_3_LUCID.dll
GenApi_MD_VC140_v3_3_LUCID.dll
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
KERNEL32.dll
mscoree.dll

For the Arena_v140.dll, GCBase..., and GenApi... files, I tried including them in the project, but it didn't make a difference.

Note that while the ArenaNET_v142.dll file requires the vcruntime, it appears to be an interop dll. I don't have to use any p/invoke or anything like that to call into it. If I include it in my WinUI project, managed types show up in the Intellisense in Visual Studio. It's just when I run and hit a line of code that calls into the dll that it crashes.

[DarranRowe]

For the rest of those dependencies. You already know about the VC++ redist files. The files listed as api-ms-... are API set libraries. They don't have to physically exist, but the library loader knows the names. All three of those should forward to ucrtbase.dll. Finally, kernel32.dll, mscoree.dll and ucrtbase.dll all exist in the Windows system directory.
But what about the dependencies of GCBase and GenApi? The name indicates that they were also built using VC, do they have any extra dependencies?
Finally, remember that System32 is always somewhere in the DLL search order. System32 would be redirected to SysWoW64 for 32 bit applications. This means that on your developer machine, you can use the directory, with care, to help resolve issues.

The VC Redistributable can be installed and it can resolve the dependency. To show this in action, if I enable native debugging in my sample application, then it will listen for and show native events. Now, if I step into the platform invoke call:

The debug events in the bottom right pane shows that it loaded vcruntime140.dll from the UWPDesktop package directory. So, what happens if I remove the PackageDependency for the VC libraries?

The debugger shows that it is being loaded from System32.

So while you should be very careful about what you are placing in this directory, if you trust the libraries, you can place them into the directory temporarily to see if it helps resolve the dependencies. But just be aware, the debugger only shows the loads if Windows successfully loads the library and all dependencies. This is why I suggested Process Monitor to look at filesystem access. Windows will access the filesystem to try to find the dependencies prior to loading them.