Packing a control library puts generic.xbf in the wrong folder

[dotMorten]

Describe the bug When I'm packing a control class library with a generic.xaml file, the compiled xbf id placed in the folder \lib\net5.0-windows10.0.18362.0\MyControls\Themes\Generic.xbf whereas the generated .dll and .pri is placed in : \lib\net5.0-windows10.0.18362\MyControls.dll (without the added .0 to the path)

Steps to reproduce the bug

1. Unpack the following repro: MyControls.zip
2. Open a dev command prompt and run: msbuild /restore /t:Pack MyControls.csproj
3. Unzip the generated nuget package and note the following file structure:

\MyControls.nuspec
\[Content_Types].xml
\lib\net5.0-windows10.0.18362\MyControls.dll
\lib\net5.0-windows10.0.18362\MyControls.pri
\lib\net5.0-windows10.0.18362.0\MyControls\Themes\Generic.xbf
\lib\uap10.0.17134\MyControls.dll
\lib\uap10.0.17134\MyControls.pri
\lib\uap10.0.17134\MyControls\Themes\Generic.xbf

Note how the .xbf file is in the .0 folder, and the .dll files aren't.

Expected behavior Generic.xbf below where the .dll and .pri file resides.

Version Info

NuGet package version: [Microsoft.WinUI 3.0.0-preview4.210210.4]

Windows app type:	UWP	Win32
Yes	Yes

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
October 2020 Update (19042)
May 2020 Update (19041)
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop
Xbox
Surface Hub
IoT

Additional context

[ranjeshj]

@fabiant3 @evelynwu-msft as FYI

[evelynwu-msft]

This feels like a Nuget issue... @fabiant3 what contacts do we have on the Nuget team?

@dotMorten Do you know if this is something that used to work, or is this the first time you've tried this scenario?

[dotMorten]

I started second-guessing myself here. I removed @clairernovotny's MSBuild SDK Extras (and the multi targeting), and the added .0 seems to disappear. I couldn't find anywhere in the msbuild logs where the value without the .0 comes from, so I'm guessing there's a build task that has hard-coded the TFM without the .0 ? Is the issue that WinUI isn't always adding the extra .0 even if that is the TFM? Another difference is that you now get generic.xaml file instead of generic.xbf

I don't believe this is a recent regression.

[evelynwu-msft]

WinUI shouldn't be doing anything special here... the TFM is derived by the .NET project system from the TargetFramework property present in the project file, and WinUI does not try to manipulate it.

[dotMorten]

One more thing: Removing the extra .0 from the TFM seem to resolve the issue, however that's different from what the WinUI project templates are using.

[evelynwu-msft]

Thanks, that should be useful information for whoever we find to help us investigate this.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[dotMorten]

Retried with 1.3.230724000. Still an issue. Repro updated with latest winappsdk: MyControls_v2.zip