Multi-targeting WinUI and WPF on Windows 10 with Windows Runtime API

[newky2k]

I have a number of open-source libraries that use Multi-targeting to create a single package for multiple targets. I'm now updating these libraries to add support for WinUI and under typical circumstances the standard approach using TFMs, conditional 'PropertyGroup' and 'ItemGroup' entries works fine.

However, on one of my projects we are using WPF, .NET 6 and need to use the Windows Runtime API. In order to do this you have to set an explictly versioned TFM, e.g net6.0-windows10.0.18362.0.

This now causes a conflict with WinUI as the TFM is also an explict version e.g. net6.0-windows10.0.18362.0.

Firstly there isn't a way of specifing a different library for WPF and WinUI for the same TFM and if i include both 'UseWPF' and 'UseWinUI' that it will include framework references that are not needed.

Even if I include a net6.0-windows7.0 the net6.0-windows10.0.18362.0 version is installed instead, adding the WinUI packages unnecessaily.

The only option i have it to create a seperate project, which loses a lot of the benefits of multi-targeting in the first place.

Any ideas how to work roung this problem?

This is an example of the frameworks definition.

<TargetFrameworks>netstandard2.0;netcoreapp3.1;Xamarin.iOS10;Xamarin.Mac20;Xamarin.TVOS10;Xamarin.WatchOS10;MonoAndroid80;MonoAndroid81;MonoAndroid90;MonoAndroid10.0;tizen40;</TargetFrameworks>
      <TargetFrameworks Condition=" '$(OS)' == 'Windows_NT' ">$(TargetFrameworks);uap10.0.18362;net5.0-windows7.0;net5.0-windows10.0.18362;</TargetFrameworks>

And the PropertyGroup and ItemGroup

<PropertyGroup Condition=" $(TargetFramework.StartsWith('net5.0-windows10')) ">
    <UseWinUI>true</UseWinUI>
    <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
    <RuntimeIdentifiers>win10-x86;win10-x64;win10-arm64;win10-arm</RuntimeIdentifiers>
    <DefineConstants>$(DefineConstants);WINUI</DefineConstants>
</PropertyGroup>


<ItemGroup Condition=" $(TargetFramework.StartsWith('net5.0-windows10')) ">
	<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.0.0" />
	<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22000.194" />

	<Compile Include="**\*.winui.cs" />
	<Compile Include="**\*.winui.*.cs" />

</ItemGroup>

[zivkan]

Firstly there isn't a way of specifing a different library for WPF and WinUI for the same TFM and if i include both 'UseWPF' and 'UseWinUI' that it will include framework references that are not needed.

If the only thing you want is for NuGet to not force the consuming project to add <FrameworkReference ... />, with the knowledge that when the consuming project is using WPF or WinUI, that the project will have it anyway, then I suggest creating a Feature Request, asking for a pack to use a SupressFrameworkReferences property, or similar, to work similar to how SuppressDependenciesWhenPacking and IncludeBuildOutput work. Note, this still means that you'll have a single assembly per unique "NuGet Target Framework" (includes both MSBuild properties TargetFrameworkMoniker and TargetPlatformMoniker), which means that a WPF project using your package will see (available in IntelliSense and compile time) your WinUI APIs, and WinUI projects using your package will see your WPF APIs. If your package consumers use the "wrong" API, there will be no safeguard unless you also create your own Roslyn Analyzer, or they won't know until runtime when they get an exception.

Again, if this is all you want, you can work around this by not using a NuGet generated nuspec, but having one you maintain yourself, docs here on how to pack with your own nuspec. Another idea is to have a build/pack script that runs dotnet pack -p:ContinuePackingAfterGeneratingNuspec=false, edits the generated nuspec to remove the parts you don't want, then pack a second time, this time with NuspecFile=path\to\YourPackage.nuspec instead of ContinuePackingAfterGeneratingNuspec=false.

If, however, you want to have different APIs for WinUI and WPF, then that's something that NuGet doesn't support as NuGet's only "pivot point", for automatic asset selection, is target framework. Therefore, if both your WPF and WinUI code use the same "NuGet Target Framework", then NuGet doesn't have the capability to do different things.

I see one option as creating separate packages. You mentioned using different projects, that's probably the best way. Also you could move common code into a third project/package if you're concerned about code duplication across two projects. But you could also get by with a single project using multiple "configurations", one of which is for WPF, the other WinUI, but this means that your build scripts will need to restore and build the project/solution twice, once for each configuration.

You could also create an issue in https://github.com/dotnet/sdk asking them to work with the NuGet team (and WPF/WinUI teams?) to design a solution that can allow WPF and WinUI libraries, without adding unnecessary framework references. But you might want to pre-emptively justify why having two different packages with WPF/WinUI specific code, and a third with shared common code used by the other others, is not a suitable solution. Spending time implementing features with workarounds means we won't have time to work on other new features, so understanding the impact helps us prioritize more effectively.

Another option is to use NuGet only as a MSBuild extensibility point. Don't let NuGet put your assemblies under lib/, or put FrameworkReferences in the nuspec,. Include your own build/net5.0-windows10.0.17763.0/PackageId.targets that has MSBuild logic to detect when the consuming project uses WPF or WinUI, and then add in the appropriate things yourself, such as <Reference Include="Your.dll"><HintPath>$(MSBuildThisFileDirectory)\Wpf\Your.dll</HintPath></Reference>, or whatever NuGet & the .NET SDK do when we do asset selection for you.

Condition=" $(TargetFramework.StartsWith('net5.0-windows10'))

You can consider using Condition=" '$(TargetFrameworkIdenfier)' == '.NETCoreApp' && [MSBuild::VersionGreaterThanOrEquals('$(TargetFrameworkVersion)', '5.0')] && '$(TargetPlatformIdenfier)' == 'windows' " (I might not have got the syntax exactly right, but you get the idea). It's longer, but it will avoid needing to be maintained if you ever decide to add Windows 11 specific APIs (so your project targets both net6.0-windows10.0.whatever and net6.0-windows11.0.whatever, or if you end up with net5.0-windows and net6.0-windows, and so on. Using TargetFrameworkIdentifier also lets you easily distinguish between .NETFramework and .NETCoreApp, which is much tricker if you try to parse TargetFramework instead, as you're doing, which dotnet/project-system explicitly calls out as something not to do, at least in their own codebase.

[newky2k]

@zivkan I was afraid that was going to be the case. One of the main benefits of having it all in one multi-targetted library is that output dlls all share the same public key so that its easy for the applications to substitute when working with shared and platform specifiic code.

On one of my projects i've split it to three libraries - Core, WPF and UWP/WinUI so you have to specfically add the right library, but its feels clunky compared to multi-targeting.

I'll eventually drop support for .NET framework, as i suspect most people will.

I guess it'd be nice to able so specify confitional restore options (E.g if net6-windows10 and UseWPF then use this TFM) in the package to override the automatic process.

Thanks though for confirming what i thought.