Adding User Experience for creating WinMDs on .NET Core

We’re planning on adding a new WinRT host in core-setup to enable users to author WinRT components that run on .NET Core 3.0 and are activated via the upcoming side-by-side WinRT resolution, Reg-Free WinRT. See dotnet/core-setup#5527

We should add support in the SDK to enable users to “relatively” easily author a WinRT .NET Core 3.0 component.

As per the design in dotnet/core-setup#5527, my plan is to resolve the WinRT host the same way that the .NET Core App Host or the .NET Core COM Host are currently resolved. After resolving the host, we will copy the host to the output directory and rename it to be the output name of the component with a .dll suffix.

The user will enable creating a WinRT .NET Core 3.0 component by setting the <OutputType> to winmdobj in their .csproj. MSBuild and the SDK already have all of the targets and tasks wired up correctly to to generate a .winmd when the user specifies an output type of winmdobj, so there minimal work needed on that end.

Current open issues:

• WinMDExp is only available on Desktop MSBuild. We can either make this available in Core MSBuild or require users to use Desktop MSBuild to build these WinMDs.
• WinMDExp only supports full PDBs. My suggestion is to change the default debug type for winmdobj projects to be full instead of portable.
• The user will need to add a reference to Windows.Foundation.winmd. The Windows team is currently working on a new metapackage (Microsoft.Windows.SDK.Contracts) that is currently on MyGet (https://dotnet.myget.org/gallery/windows-sdk-beta). This package can be referenced by users to fulfill this requirement.

[clairernovotny]

Please fix WinMDExp to support portable and embedded PDB’s. Do not want full pdb’s and those also cannot go to the NuGet symbol server.

[jkoritzinsky]

cc: @tommcdon @cshung