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.

[anti-matter]

Ok, thanks @AArnott, I think we figured it out.

In the sample, the using path is Microsoft.Windows.SDK, but for some reason, in our project, it must be Microsoft.Windows.Sdk. Using that camel case seems to have fixed our issue. Such a small thing. :)

[AArnott]

@anti-matter What sample uses Microsoft.Windows.SDK with all-caps for SDK? That's a bug and wouldn't work anywhere. The sample .zip in the issue description doesn't have this issue -- I just checked.

[inthemedium]

@AArnott does this fix apply to WPF non-core (WPF framework?)?

i.e.

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>        
    <TargetFramework>net45</TargetFramework>
    <IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
   ...

I didn't see the property when searched the binlog, so I'm guessing no. Is there a place I can file a bug to get this fixed there too?

[AArnott]

@inthemedium, I'm told that it should work, provided you are building with the required SDK version.

I didn't see the property when searched the binlog

Then something else is wrong, since you are setting the property, it should be there.

[inthemedium]

@AArnott , figured out the issue. I needed to add <UseWPF>true</UseWPF> for the project to be formally recognized as a SDK-style WPF project. After that the new flag works

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>        
    <TargetFrameworks>net45</TargetFrameworks>
    <IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
    <UseWPF>true</UseWPF>
....

[lindexi]

It seems to be fixed in dotnet 6.

[AArnott]

True. The .NET 6 SDK includes the new behavior as on by default whereas .NET 5 SDK had it off by default.

[zhylmzr]

If anyone has this problem in .NET 6, try to install 0.1.422-beta version.

[AArnott]

@zhylmzr, that's quite an old version of CsWin32. Do you find it works better than the latest version?

[zhylmzr]

@AArnott The newst version doesn't work in my environment, same error message.

[MddMBorg]

Does anyone have a fix for this in .NET 6? I have a WPF project but receive the following when compiling:

error CS0101: The namespace 'NameSpace' already contains a definition for 'Type'

Where the namespace and type is defined in my Source generator. This had no issues in .net 472 with SDK style project, but have recently upgraded.

The project has the following tags:

	<PropertyGroup>
		<OutputType>WinExe</OutputType>
		<TargetFramework>net6.0-windows</TargetFramework>
		<UseWPF>true</UseWPF>
		<UseWindowsForms>true</UseWindowsForms>
		<deterministic>false</deterministic>
		<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
		<EnableNETAnalyzers>true</EnableNETAnalyzers>
		<AnalysisLevel>none</AnalysisLevel>
		<IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
	</PropertyGroup>

[AArnott]

@MddMBorg Check out #601, which sounds like what you're hitting.