WinRT.Host/WinRT.Host.Shim copied to output of app with project ref to projection library

[angelazhangmsft]

CsWinRTIssue.zip

WinRT.Host.Shim.dll gets copied always. We're also setting Platforms = x64 and (not in this sample) RuntimeIdentifier = win10-x64 which also makes it copy WinRT.Host.dll. In this sample it's in the runtime subfolder, but it still gets copied.

Originally posted by @A-Ovchinnikov-mx in https://github.com/microsoft/CsWinRT/issues/1031#issuecomment-955375947

[j0shuams]

Initial findings show that the library, that actually references C#/WinRT, (correctly) does not output those files. During the app's builds, the project reference introduces a package dependency. When resolving the cswinrt dependency upstream, nuget/msbuild are automatically including files from the lib and runtimes folder of the cswinrt nuget package, probably by a naming convention.

Looking into potential solutions. We have a target that handles this, but the targets (build) are not pulled in (like lib) by the package dependency.

[ghost]

Hi @j0shuams, I see that in Microsoft.Windows.CsWinRT.targets there is a target that actually removes unused references to these files:

https://github.com/microsoft/CsWinRT/blob/master/nuget/Microsoft.Windows.CsWinRT.targets#L21

I believe this .targets file should be in a buildTransitive folder to be picked up by the app project.

[j0shuams]

Yes that will get the .targets file pulled in, causing the target that blocks Host/Host.Shim to take effect. However it will also expose the rest of the targets to the CsWinRTIssue project, which will cause errors. Particularly, it will try to generate a projection and fail. A workaround for this new error would be to add <CsWinRTEnabled>false</CsWinRTEnabled> to the CsWinRTIssue.csproj. How does that sound?

[j0shuams]

Assuming the above is not desirable, we tried an alternative solution of an additional .targets in buildTransitive. The new file takes care of the issue you are seeing, without adding extra targets. However, for this file to be run, NuGet requires it have the same name as the package. Which then shadows the real targets (from build) causing a new error upstream in the library. Seems we're at an impasse but we will continue to look for a good solution.

As a quasi-workaround, you could prevent WinRT.Host.dll from flowing downstream by adding ExcludeAssets="runtimes" on the CsWinRT NuGet PackageReference.

[ghost]

Hi @j0shuams, sorry for the late reply, I wasn't actively working on this code for the past few days 😬

Thank you for the update!

Indeed adding CsWinRTEnabled to the app project would be undesirable, though it would work as a temporary workaround. (Not so if there are more downstream projects though)

I've also tried doing the following but it didn't work:

    <PackageReference Include="Microsoft.Windows.CsWinRT" Version="1.3.5"
                      Condition="'$(TargetFramework)' == 'net5.0-windows'"
                      GeneratePathProperty="true" PrivateAssets="all" />
...
  <ItemGroup Condition="'$(TargetFramework)' == 'net5.0-windows'">
    <Reference Include="WinRT.Runtime">
      <HintPath>$(PkgMicrosoft_Windows_CsWinRT)\lib\net5.0\WinRT.Runtime.dll</HintPath>
    </Reference>
  </ItemGroup>

[j0shuams]

Hi @A-Ovchinnikov-mx , no worries. In our meeting this was decided as a p2, so the attention it gets might slow down for a bit. I have reached out to someone with NuGet, though, to see if they have some ideas.

I think you've got a good idea there, but you might need to update more than just Reference. ReferencePath and ReferenceCopyLocalPath come to mind in particular.

Also, and you might know this, you can use the /bl option when building the project (from CL) to get a MSBuild BinLog that would illuminate why what you have there doesn't work. You can do the same thing in VS with the instructions here - https://docs.microsoft.com/en-us/visualstudio/ide/how-to-view-save-and-configure-build-log-files?view=vs-2019#use-binary-logs-to-make-it-easier-to-browse-large-log-files

I hope this helps, and I'll report back with any additional findings.