Microsoft-ui-xaml: Proposal: Remove the need to specify XAML files in project files

[mrlacey]

Proposal: Remove the need to specify XAML files in project files

Summary

"WinUI in Desktop" apps use the new SDK style projects but still require specifying the *.xaml files explicitly. The need to specify them here should be removed.

Rationale

• Will make managing files in a project easier.
• The expectation of SDK file projects is that all projects in the directory are included by default. The current behavior breaks this convention and risks causing confusion.

Scope

Important Notes

I understand that this is mostly a restriction of Visual Studio (and possibly also MSBuild) but have created this issue on the recommendation of the team as a way to track this.

Open Questions

[maxkatz6]

It should be fixed with migrating to new .Net core SDK.

[StephenLPeters]

@stevenbrix for FYI

[stevenbrix]

Adding @davkean and @davidwengier

We had the same issue in WPF, and are doing the same thing that they did to fix it: https://github.com/dotnet/wpf/issues/685

We're doing the same globbing that WPF does, but it doesn't seem to be working. Any ideas?

[stevenbrix]

For reference, here is what we are doing:

 <!--
    Enable default items for .NET projects that are using the SDK-style projects
  -->
  <ItemGroup Condition="'$(EnableDefaultItems)' == 'true' and '$(UsingMicrosoftNETSdk)' == 'true'">
    <ApplicationDefinition Include="App.xaml"
                           Condition="'$(EnableDefaultApplicationDefinition)' != 'false' And Exists('$(MSBuildProjectDirectory)/App.xaml') And '$(MSBuildProjectExtension)' == '.csproj'">
      <Generator>MSBuild:Compile</Generator>
    </ApplicationDefinition>
      <Generator>MSBuild:Compile</Generator>
    </ApplicationDefinition>

    <Page Include="**/*.xaml"
          Exclude="$(DefaultItemExcludes);$(DefaultExcludesInProjectFolder);@(ApplicationDefinition)"
          Condition="'$(EnableDefaultPageItems)' != 'false'" >
      <Generator>MSBuild:Compile</Generator>
    </Page>

    <None Remove="**/*.xaml"
          Condition="'$(EnableDefaultApplicationDefinition)' != 'false' And '$(EnableDefaultPageItems)' != 'false'" />

    <Content Include="Assets/**/*.*" Condition="'$(EnableDefaultAssets)'=='true'"/>
  </ItemGroup>

I can remove the entries that VS puts into the project file and those files are still being picked up and passed to the Xaml Compiler, so this does seem to be working (to some extent)

[davkean]

Point me to your SDK?

[stevenbrix]

https://dev.azure.com/microsoft/winui/_git/microsoft-ui-xaml-lift?path=%2Fpackaging%2Fbuild%2FMicrosoft.WinUI.props

[davkean]

That looks like a NuGet package? Globs can't come from NuGet packages, VS opens the project before they exist.

[stevenbrix]

Ahh I see, that's good to know. Even after the Nuget has been restored?

Adding @vatsan-madhavan and @ryalanms

We were originally planning on making an MSBuild SDK, but then didn't because we heard that the Microsoft.NET.Sdk.WindowsDesktop was going away. Is this still the plan?

[davkean]

The WindowsDesktop is merged into another SDK.

SDK's were invented entirely to fix globbing.

[stevenbrix]

The WindowsDesktop is merged into another SDK.

I'm not exactly sure what you mean? My understanding was that WindowsDesktop was going away because it makes multi-targeting impossible. If this isn't correct, then we can bring back our msbuild sdk. If it is correct, and it's being folded into the Microsoft.NET.Sdk, then we'll need to make sure the globbing works for WinUI projects as well.

[vatsan-madhavan]

IIRC It’s being folded into net.sdk. But net.sdk.windowsdesktop would have to be retained to ensure that projects migrating from 3.1 -> 5 keep on working. So we’ll likely have both worlds - net.sdk as the mainstream scenario, and net.sdk.windowsdesktop as a fully functional alternative. I suspect that the implementation details would still stay on in net.sdk.windowsdesktop for some time.

@fabiant3 is the authority on these plans nowadays btw. 😉

[fabiant3]

@vatsan-madhavan , I was considering migrating from 3.1 to 5 from a project plan is the thing you do if you want to be running in 5. I wasn't thinking about supporting 3.1 project style and compile with net5. So yeah, support net.sdk only. Appreciate your thoughts.

[stevenbrix]

@fabiant3 is there a GitHub issue tracking this work? We'd like to make sure that this works for WinUI, so if we need a property like UseWinUI, then we can do that.

[davkean]

I wasn't thinking about supporting 3.1 project style and compile with net5. S

The tooling must be backwards compatible, we only ship one in VS and it supports all versions.

[marb2000]

So, @stevenbrix @davkean @fabiant3 what is the status on this request?

[stevenbrix]

Work needs to be done to add support for WinUI to the Microsoft.NET.WindowsDesktop.Sdk for this. I just filed https://github.com/dotnet/wpf/issues/3245 to track this.

[fabiant3]

@ryalanms for awareness.

[stevenbrix]

@mrlacey, I'm going to keep this open to track the work required after https://github.com/dotnet/sdk/issues/12520