Namespaces of Interfaces packed in NuGets are ignored by CsWinRT, why?

[gmgallo]

Hi hopefully someone knows the proper way to solve this or perhaps is a bug?
I've been authoring a number of C++/WinRT components projected and packed in NuGets for a year+ and ran into a problem with custom interfaces also packed in NuGets for internal use. The problem is that when I try to build the projection of a component using interfaces from the NuGet, CsWinRT aborts with the error:
EXEC : error : 'Type 'MyInterfaces.IAnInterface' could not be found' when processing MyNamespace.MyComponet

I'm also including the NuGet in the CsWinRT project. The interface .WinMD file is where it should be in the NuGet structure and listed in the corresponding .target file because a regular C# apps and C++/WinRT components can see the namespace and use the interfaces. For example, If I hardcode the reference to the interface .WinMD in the projection .csproj like this:

<ItemGroup>
<!-- Reference the interface projection so it is not recreated in the projection of each component creating namespace collisions -->
	<Reference Include="MyInterfaces.Projection">
		<HintPath>..\..\_Interfaces_\_build\x64\Release\MyInterfaces.Projection\bin\MyInterfaces.Projection.dll</HintPath>
	</Reference>
	<Reference Include="MyInterfaces.IAnInterface">
		<HintPath>..\..\_Interfaces_\_build\x64\Release\MyInterfaces.Contract\bin\MyInterfaces.IAnInterface.winmd</HintPath>
		<IsWinMDFile>true</IsWinMDFile>
	</Reference>
</ItemGroup>

The Item group above in the projection .csproj works reliably as a temporary workaround. Those references are repeated in the .targets file of the intefaces NuGet like this:

<ItemGroup>
	<!-- Reference the interface projection DLL so the project sees IAnInterface -->
	<Reference Include="MyInterfaces.Projection">
		<HintPath>$(MyInterfacesProjectionPath)</HintPath>
	</Reference>
	
	<!-- Reference the interfaces WinMD so the projection sees the interfaces definitions -->
	<Reference Include="MyInterfaces"  >
		<HintPath>$(CsMyInterfacesWinmdPath)</HintPath>
		<IsWinMDFile>true</IsWinMDFile>
	</Reference>
</ItemGroup>

The ItemGroup above is in the .targets file under the NuGet build directory where C# code looks for, and works perfectly in a normal C# app, but interstingly, in the CsWinMD project, only the projection dll is added to the referenced assemblies but the .WinMD reference is ignored, resulting in the compile error listed above.

[RKS (rksharma-owg)]

This may now be partly addressed by recent CsWinRT 3.0 packaging changes, although the exact result depends on whether your interface package is a CsWinRT reference projection or a custom WinMD package.

Two relevant changes landed very recently:

• #2533 makes reference projections pack their reference assembly and WinMD inputs into the NuGet package (ref/ and metadata/) instead of requiring custom packing targets.
• #2585 adds a CsWinRTGenerateReferenceProjection marker so consuming projects can identify reference-projection outputs reliably.

If your package is using the CsWinRT 3.0 reference-projection model, I would first try the latest package containing those changes and inspect the restored package to confirm the .winmd is present under metadata/. That is the supported packaging path now, and it is preferable to repeating a raw <Reference IsWinMDFile="true"> item in every consuming project.

If this is instead a custom NuGet that merely ships an arbitrary WinMD plus a projection DLL, those changes may not cover it. In that case the useful next diagnostic is the evaluated MSBuild graph for the CsWinRT project: check whether the .targets import runs for the project and whether the WinMD reaches the item group consumed by the projection generator. The fact that ordinary C# consumption sees the reference does not necessarily mean the CsWinRT authoring target will consume it.

[gmgallo]

Hi RKS,
Thanks for your comments. All my projections are made with CsWinRT 2.2.0 so far. While trying to make this work I briefly tried 3.0 but ran into a problem when trying to consume the NuGet produced with it (I don't recall the specifics of the problem right now). So, I went back to 2.2.0. I'll give 3.0 a try again and find out if what you pointed out fixes the problem. As for the NuGets themselves, they are as simple as they can be just for internal code reuse. Not for publication.