Override GetResolvedWinMD to make sure all native build targets are aware of the C++/WinRT produced WinMD.

[Johan Laanstra (jlaanstra)]

Since the project templates no longer set the flags that enable the MSBuild logic to tell MSBuild about the CX generated WinMD, we have to override the GetResolvedWinMD target to ensure that VS and MSBuild pick up the correct WinMD project output. Unfortunately the target is not very extensible, so we have to override it.

VS uses this to resolve project output and without this change the PrimaryWinMDFullPath itemgroup is empty resulting in VS being unable to add project references to C++/WinRT projects.

TODO:

• Verified NuGetTest.sln in VS and using MSBuild.
• Verified that a C# app can reference and activate types from RuntimeComponent.
• Verified Razzle builds.

Fixes#425

[Scott Jones (Scottj1s)]

I'm a bit nervous about overriding all these internal CX targets. That has the potential to make our nuget brittle (or at least specific to VS versions). What's wrong with the alternative of just setting GenerateWindowsMetadata back to true for the RC project template? You describe that as a "workaround" - how so?

[Johan Laanstra (jlaanstra)]

These are standard OutputGroup targets, meant to be overriden.

[Johan Laanstra (jlaanstra)]

Scott Jones (@Scottj1s) the other option is for us to override the GetResolvedWinMD target, to make it aware of the C++/WInRT WinMD. Thoughts?

[Kenny Kerr (kennykerr)]

Have we confirmed that:

• this allows both C#->C++ project references and
• activation works in that scenario automatically and
• a basic Razzle project builds successfully?

[Johan Laanstra (jlaanstra)]

Kenny Kerr (@kennykerr) Added todo's, so you can see what I have verified.

[Scott Jones (Scottj1s)]

typo

[Scott Jones (Scottj1s)]

ok, let's give it a spin with vsix/razzle