Publishing an unpackaged Windows app fails by default

[eerhardt]

Description

Trying to publish an unpackaged Windows app raises an error that a AppxManifest is specified.

❯ dotnet publish -f net6.0-windows10.0.19041.0 -c Release -p:WindowsPackageType=None
Microsoft (R) Build Engine version 17.2.0-preview-22178-04+ce7523296 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
C:\Users\eerhardt\.nuget\packages\microsoft.windowsappsdk\1.0.2\buildTransitive\Microsoft.Build.Msix.Packaging.targets(
144,5): error : Improper project configuration: WindowsPackageType is set to None, but a AppxManifest is specified. [C:
\DotNetTest\MauiTest\MauiTest.csproj]

Steps to Reproduce

1. dotnet new maui
2. Temporary workaround to bring in the 1.0.2 windows sdk. Add the following to the .csproj:

	<ItemGroup>
	  <PackageReference Condition="$(TargetFramework.Contains('-windows'))"
	                    Include="microsoft.windowsappsdk"
						Version="1.0.2" />
	</ItemGroup>

3. dotnet publish -f net6.0-windows10.0.19041.0 -c Release -p:WindowsPackageType=None

Version with bug

Unknown/Other (please specify)

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

All Windows

Did you find any workaround?

No response

Relevant log output

Microsoft (R) Build Engine version 17.2.0-preview-22178-04+ce7523296 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
C:\Users\eerhardt\.nuget\packages\microsoft.windowsappsdk\1.0.2\buildTransitive\Microsoft.Build.Msix.Packaging.targets(
144,5): error : Improper project configuration: WindowsPackageType is set to None, but a AppxManifest is specified. [C:
\DotNetTest\MauiTest\MauiTest.csproj]

cc @mattleibow

[Redth]

Related to #5884

[mattleibow]

This should fix it #5896

[mattleibow]

Linked to #3166

[eerhardt]

I'm re-opening this issue because this scenario doesn't fully work. #5896 fixed the above error, but past that it still runs into an error:

❯ dotnet publish -f net6.0-windows10.0.19041.0 -c Release -p:WindowsPackageType=None /bl
Microsoft (R) Build Engine version 17.2.0-preview-22178-04+ce7523296 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

C:\git\maui\bin\dotnet\sdk\6.0.300-preview.22204.3\MSBuild.dll -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\git\maui\bin\dotnet\sdk\6.0.300-preview.22204.3\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\git\maui\bin\dotnet\sdk\6.0.300-preview.22204.3\dotnet.dll -maxcpucount -property:Configuration=Release -p:WindowsPackageType=None -target:Restore -verbosity:m /bl .\MauiTest2.sln
  Determining projects to restore...
  All projects are up-to-date for restore.
C:\git\maui\bin\dotnet\sdk\6.0.300-preview.22204.3\MSBuild.dll -nologo -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\git\maui\bin\dotnet\sdk\6.0.300-preview.22204.3\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\git\maui\bin\dotnet\sdk\6.0.300-preview.22204.3\dotnet.dll -maxcpucount -property:TargetFramework=net6.0-windows10.0.19041.0 -property:Configuration=Release -p:WindowsPackageType=None -target:Publish -verbosity:m /bl .\MauiTest2.sln
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
C:\git\maui\bin\dotnet\sdk\6.0.300-preview.22204.3\Microsoft.Common.CurrentVersion.targets(2491,5): error MSB4062: The "Microsoft.Build.Tasks.GetInstalledSDKLocations" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.  Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\DotNetTest\MauiTest2\MauiTest2.csproj]

Digging into this error, it appears the problem is that setting WindowsPackageType is causing an SDKReference item to get added to the project. This in turn is causing the above Task to get invoked.

The reason this happens is because of these targets in WinUI:

  <!-- By default, add CRT package dependencies for WAP-free and UAP apps.  Previously, this was done to satisfy
      CRT linkage for WinUI 3 binaries.  With Hybrid CRT, that's no longer needed, but we retain this behavior 
      to avoid breaking existing projects.  At deployment time, it's very likely that a target device will already
      have Microsoft.VCLibs and Microsoft.VCLibs.Desktop FWPs installed.  But apps can still opt out of referencing
      these FWPs by setting WinUISDKReferences='false'. -->
  <PropertyGroup Condition="'$(WinUISDKReferences)'=='' and ('$(TargetPlatformIdentifier)'=='UAP' or '$(WindowsPackageType)'!='')">
    <WinUISDKReferences>true</WinUISDKReferences>
  </PropertyGroup>

  <ItemGroup Condition="'$(WinUISDKReferences)'=='true' and
                      ('$(OutputType)' == 'Exe' or 
                      '$(OutputType)' == 'AppContainerExe' or 
                      '$(MSBuildProjectExtension)'=='.wapproj' or
                      ('$(OutputType)'=='WinExe' and '$(EnablePreviewMsixTooling)'=='true'))">
    <SDKReference Include="Microsoft.VCLibs, Version=14.0" />
    <SDKReference Include="Microsoft.VCLibs.Desktop, Version=14.0" />
    <SDKReference Include="Microsoft.UniversalCRT.Debug, Version=$(TargetPlatformVersion)" Condition="'$(Configuration)' == 'Debug'" />
  </ItemGroup>

Since '$(WindowsPackageType)'!='' is true, WinUISDKReferences gets set to true. Then the ItemGroup kicks in and adds those SDKReference items, which causes the GetInstalledSDKLocations task to run, which doesn't exist in .NET Core MSBuild:

https://github.com/dotnet/msbuild/blob/931ff51f0e70bc8ba16003bfda0b871ee7379994/src/Tasks/Microsoft.Build.Tasks.csproj#L545-L602

It is only compiled on .NET Framework.

I believe this is a bug in the WinUI targets. The reason it doesn't happen by default is because $(WindowsPackageType) isn't set until AFTER the above check that is setting WinUISDKReferences. In my current install, the above xml is around line 13,000 of my preprocessed project. The code that defaults WindowsPackageType is around line 15,000:

  <PropertyGroup>
    <!--
      The below table describes the available options for packaging and what they mean.
      These are controlled through the WindowsPackageType property.

        |   WindowsPackageType |  App Model Type | Produces .msix | Has Identity |
        |======================|=================|================|==============|
        |        None          |     Win32       |       No       |     No       |
        |        MSIX          |     Win32       |       Yes      |     Yes      |
        |       Sparse         |     Win32       |       No       |     Yes      |

       If there exists a Package.appxmanifest file, then we'll default into MSIX.
       If there is no Package.appxmanifest, then the default is None.
    -->
    <WindowsPackageType Condition="'$(WindowsPackageType)'=='' and Exists('Package.appxmanifest')">MSIX</WindowsPackageType>
    <WindowsPackageType Condition="'$(WindowsPackageType)'==''">None</WindowsPackageType>

    <!-- Need to set to 'true' so that VS enables the 'Project -> Publish' menu and the 
         .appxmanifest designer -->
    <WindowsAppContainer Condition="'$(WindowsPackageType)'=='MSIX'">true</WindowsAppContainer>
  </PropertyGroup>

Since WindowsPackageType isn't set until after, these SDKReference items don't get added by default. They only get set if WindowsPackageType is set in the user's project, or on the command line.