Workaround for WPF PackageReference and source generators bug

[AArnott]

When developing a WPF project, dotnet/wpf#810 and dotnet/wpf#3963 will cause the WPF "inner build" to omit important elements to source generators, leading to build breaks anywhere you use the generated code as reported by a *_wpftmp.csproj project file.

For example you may see a compiler error as if the generated types do not exist:

D:\temp\WpfApp1\WpfApp1\MainWindow.xaml.cs(15,25): error CS0234: The type or namespace name 'Sdk' does not exist in the namespace 'Microsoft.Windows' (are you missing an assembly reference?) [D:\temp\WpfApp1\WpfApp1\WpfApp1_2gbqycls_wpftmp.csproj]

To fix this you must use the .NET 5.0.102 SDK and set the following property in your project:

<IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>

To make sure you are using the SDK with the fix, you may need to add a global.json file with this content to the root of your repo:

{
  "sdk": {
    "version": "5.0.102",
    "allowPrerelease": false,
    "rollForward": "major"
  }
}

Here is a fully working minimal sample: wpfsample.zip

[nick-beer]

I believe I'm running into some form of this issue with a package that contains C# files in its contentFiles (with buildAction="Compile"). Setting IncludePackageReferencesDuringMarkupCompilation (when using 5.0.102, as described) does not seem to help. Are contentFiles still broken with this workaround?

[AArnott]

@nick-beer, your question sounds unrelated to this source generator and more appropriate for the WPF audience. Can you try posting your question over on the dotnet/wpf repo?

[nick-beer]

@AArnott - Shoot, I'm sorry. I'm not sure what repo I thought I was in - I just followed google from a search for IncludePackageReferencesDuringMarkupCompilation - a property that looked suspicious when debugging a build issue. I'll post to another repo - thanks!

[anti-matter]

Hello, we're trying to use CsWin32 with our .NET 5.0 WPF app and the steps above DO NOT work (we followed them exactly). We still continue to get the following error. What are we missing?

error CS0234: The type or namespace name 'SDK' does not exist in the namespace 'Microsoft.Windows' (are you missing an assembly reference?) [C:\Users\micha\source\repos\teams-client\windows-gui\windows-ui\Windows-UI_gbumtqzv_wpftmp.csproj]

Thanks in advance!

[AArnott]

@anti-matter, I have attached a .zip to a sample that works in our testing to the issue description. Does that work on your machine with dotnet build?

[anti-matter]

Thanks @AArnott for the zip. That simple project works fine for me, but I still cannot get it to work in my project. I tried to find a setting that our project has set that might be causing our build to fail, but no luck.

I did notice too that intellisense still claims there's an error with Microsoft.Windows.SDK in the sample project, but the compiler seems to ignore that it's missing. In my case, the compiler does not ignore it.

Is there a release where we expect this issue to be resolved in WPF so the work-around is not necessary?

thx.

[AArnott]

but the compiler seems to ignore that it's missing. In my case, the compiler does not ignore it.

The compiler can't and isn't ignoring it. The compiler sees it where the IDE language service does not. So given the sample project works for you at the command line but your project does not work at the command line tells us that there is something peculiar with your project that prevents the source generator from running. I suggest you compare the build logs between the sample and your project. Use the /bl switch and use the viewer at http://msbuildlog.com and focus on the Csc task invocation's Analyzers parameter to see if there are differences, to start with.

Once you get the command line build working on your project, we can focus on what remains in the IDE that could be broken, but you should probably start with trying out 16.9 Preview 3 to see if that works for you, as a lot of source generator bugs have been fixed in that release.

Is there a release where we expect this issue to be resolved in WPF so the work-around is not necessary?

The fix is already released, but it requires opt-in via the property documented above.
It may be the default behavior in the .NET 6 SDK, but I haven't heard that confirmed.