Can't load WinRT Component unless I reference the project

Question

I'm running into an odd problem. I created a Windows Runtime Component (for Windows Store) that makes some legacy C/C++ code available to .NET via some C# wrapper classes.

I wrote a test harness Store App (hereafter referred to as "test1") that references the WRC project (both projects in the same solution). It calls into the component and everything works fine.

Next I take the following output files from the WRC project:

MyWrtComponent.dll
MyWrtComponent.exp
MyWrtComponent.pdb
MyWrtComponent.pri
MyWrtComponent.winmd

...and try to use them from another Store app project ("test2"). In this project, instead of referencing the MyWrtComponent project, I add a reference to the .winmd file. Everything builds fine, but when I run the test2 app I get a System.IO.FileNotFound exception from mscorlib as soon as I try to use one of the C# classes implemented in MyWrtComponent:

at System.StubHelpers.StubHelpers.GetWinRTFactoryObject(IntPtr pCPCMD)
at MyWrtComponent.MyWrtClass..ctor()

The specified module could not be found.
(Exception from HRESULT: 0x8007007E)

Using release vs. debug build of the MyWrtComponent doesn't make any difference.

Running ProcMon on test2, I see several unsuccessful attempts at loading vccorlib120_app.DLL (or vccorlib120d_app.DLL if I'm building debug):

QueryOpen   F:\test2\bin\Debug\AppX\vccorlib120d_app.DLL    NAME NOT FOUND
QueryOpen   F:\test2\bin\Debug\AppX\vccorlib120d_app.DLL    NAME NOT FOUND
CreateFile  C:\Windows\SysWOW64\vccorlib120d_app.DLL    NAME NOT FOUND

I've confirmed that this file doesn't exist in my C:\Windows\SysWOW64 folder. I don't know whether that's relevant to my problem.

When I run test1, different locations are searched, and the file is found:

QueryOpen   F:\test1\bin\Debug\AppX\vccorlib120d_app.DLL    NAME NOT FOUND
CreateFile  C:\Program Files\WindowsApps\Microsoft.VCLibs.120.00.Debug_12.0.20827.3_x86__8wekyb3d8bbwe\vccorlib120d_app.dll SUCCESS

I compared the bin\Debug\AppxManifest.xml of both test projects, and noticed one important difference; test1 has the following and test2 doesn't:

<Dependencies>
  <PackageDependency Name="Microsoft.VCLibs.120.00.Debug" MinVersion="12.0.20827.3" />
</Dependencies>

If I add these three lines to the generated output of test2 and run the app, it works, but of course that's not a real fix.

Does anyone understand what's going on here? Does MyWrtComponent have a dependency that somehow isn't being communicated, or am I supposed to do something to package vccorlib120d_app.DLL along with my runtime component, or ... ?

Thanks in advance.

Ukulele

can you share your working sample app for UWP/C# and WinRT/c++ please? – Medor

or have a look into my problem? #67783465 – Medor

Answer 1

Well, you're running into several issues here, the first one is that as your WinRT component uses C++, you need to have a reference to the Microsoft Visual C++ Runtime Package in your app, this is something that is expected to do by the end user of your component (the app developer), so to do it, right click the References folder in the Solution Explorer of the app and go to Windows->Extensions, there select Microsoft Visual C++ Runtime Package from the list of available SDKs and click Ok.

Second, if you plan to keep this component for yourself, it's better that you reference the project as it's the easier way to do, if you plan to distribute it, then you need to create a SDK to be sure that all the pieces are together, note that this is necessary for C++ WinRT components, but not for C# or VB.NET components, the reason seems to be that C++ WinRT components are splitted into metadata (WinMD file) and implementation (DLL file), and even if you put them side by side they're unable to recognize each other, while in C# and VB.NET the metadata and its implementation are on the same file (WinMD). If you want to create an SDK, then read this documentation on MSDN.

Malamut

Answer 2

Your 2nd build is violating app-package requirements. Which state that the application package that you deliver to the Store has all of the dependencies embedded and that the application manifest lists all of those dependencies. This is a strong DLL Hell countermeasure, a Store user just has no hope of solving the kind of problem you ran into.

Adding a reference to the .winmd file keeps the compiler happy, it contains enough information to compile your source code. But the next step goes wrong, the .winmd file doesn't give the build system enough information to put the app package together. It can't figure out from just the .winmd file that your component has additional dependencies. Your main project doesn't have a dependency on Microsoft.VCLibs since it is a managed project.

It's not like you can't maintain the appxmanifest yourself. It just extra work that's way too easy to get wrong, starting with them being different for the Debug vs Release build. The next VS update is going to get you into trouble, it no doubt will have an update for Microsoft.VCLibs, requiring you to update the version number in the manifest.

Using a project reference is the simple way to always get the proper package.

Patnode

I've upvoted both answers, but I had to choose one for the bounty, and Rafael's answer had specific instructions that were helpful to me. Thanks Hans. – Ukulele