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