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.
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.