Source Generator support for WPF project blocked?

[Marvin Rühe]

Version Used:
dotnet 5 preview 8, visual studio 16.8 preview 2

Steps to Reproduce:
Create fresh WPF project from VS modify project like this:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <OutputType>WinExe</OutputType>
        <TargetFramework>net5.0-windows</TargetFramework>
        <UseWPF>true</UseWPF>
        <LangVersion>preview</LangVersion>
    </PropertyGroup>

    <ItemGroup>
	    <ProjectReference Include="..\SourceGenerators\SourceGenerators.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
    </ItemGroup>
</Project>

Expected Behavior:
The source generator referenced works for me in a console dotnet core app. I would expect this to work in a WPF project too.

Actual Behavior:
In a freshly created WPF (dotnet core) project from the VS-template, however the generator does not seem to run.

Is this intended behavior?

As the generator is not used at all, I have not included it here. It is a slight variation of the HelloWorld sample.

[Jonathon Marolf]

I believe the issue here is that the intermediate project that the WPF build creates is not passing the source generators to the compiler.

@jaredpar and @chsienki do you agree?

[Chris Sienkiewicz]

The issue is that the WPF intermediate build clears the analyzers collection as a way of disabling analyzers from running. This obviously wipes out the generators too, so we need to update the WPF targets to use the new 'SkipAnalyzers' option instead. See: dotnet/roslyn#46669

I think there is an issue for this WPF + generators problem somewhere already, but can't find it right now.

[Marvin Rühe]

Please consider documenting the lack of WPF support somewhere, because it "just doesn't work" but without any error. It took me quite a while to figure out what was the issue here and even in hindsight I couldn't find any warning.

[Jared Parsons]

Transferring this issue to the wpf repository as it appears they are not properly passing $(Analyzers) to the compiler when building their intermediate temp project. That in turn can impact build success as generators are included in that group.

[Tobias Käs]

Please consider documenting the lack of WPF support somewhere, because it "just doesn't work" but without any error.

This would be a blocking issue for adoption since it makes either source generators or WPF unusable. Just documenting that it doesn't work isn't enough, this needs to be implemented.

For example the new COM interop story (CsWinRT) is already looking at using source generators to dynamically generate code, so the amount of things WPF would be incompatible with is only rapidly going to grow from here as generators are adopted by other nuget packages.

[Jared Parsons]

Just documenting that it doesn't work isn't enough, this needs to be implemented.

Intent is to fix the behavior, not document it.

[Marvin Rühe]

What info is needed @ryalanms?

(Also, when I was asking for documentation I meant to add a known-issue that it is not working in the previews, while it is being worked on.)

[Jan Kučera]

@Marv51 from another issue

@miloush needs-more-info was merely our way of marking the issue as "we've seen it, but we don't have time in this meeting to read the whole thread, understand it, and decide what to do about it". In this case, the more-info needed is the informed opinion of a team member (me). We need a better GitHub label for this (we're actually working on this), so as not to confuse people

[Claire Novotny]

I believe this is a dup of #810 which I think is the same underlying issue. If not a dup, would be impacted by any source generators that ship as a NuGet package.

[Tobias Käs]

Not a direct dup, note that OP is using <ProjectReference> not <PackageReference>, but they are probably closely related in their underlying issue, and yes you'll probably get the same problem for generators distributed via nuget.

[Marvin Rühe]

I believe that this should get at least really looked at for 5.0?

Source Generator are a major feature of c# 9/dotnet 5.0, for them not to work in wpf seems like a problem to me.

@jaredpar, @jmarolf

[Jonathon Marolf]

CC @dotnet/dotnet-wpf as they will need to decide when this fits into their schedule

[Ivan Zalutskii]

I found a hint on how to solve the problem here #3974

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
...
    <IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
...
  </PropertyGroup>

In my case it works.

[Ryland]

Thanks for pointing this out, @Zalutskii. Existing source generator and PackageReference issues have not been linked to the source generator change: #3846. Apologies.

This was made 'opt-in' to reduce the possibility of breaking compilation of existing WPF applications, but will eventually be turned on by default in .NET 6.0.

[Marvin Rühe]

I tried the property that @Zalutskii was mentioning above IncludePackageReferencesDuringMarkupCompilation, but it does not seem to work? Or maybe that PR didn't make it into 5.0.2 after all.

One think I would like to point out, that while most people (and that attribute) are talking about PackageReference, please don't forget about ProjectReference.
At least as far as I know, referencing a source generator within the same solution should be done by ProjectReference.

Update: I did it wrong. Attribute works perfectly.

[Ivan Zalutskii]

I tried the property that @Zalutskii was mentioning above IncludePackageReferencesDuringMarkupCompilation, but it does not seem to work? Or maybe that PR didn't make it into 5.0.2 after all.

One think I would like to point out, that while most people (and that attribute) are talking about PackageReference, please don't forget about ProjectReference.
At least as far as I know, referencing a source generator within the same solution should be done by ProjectReference.

here I give an example of how to add the Source Generator as a Project Reference.
If you want to add as NuGet it will look like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
...
    <IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
...
  </PropertyGroup>
  <ItemGroup>
...
    <PackageReference Include="RxSourceGenerator" Version="1.1.2" />
...
  </ItemGroup>

Microsoft Visual Studio Community 2019 16.8.4
If you use resharper, it must be the latest version, or disabled.

[Nukepayload2]

I'm trying to port VB "My WPF extension" of .NET Framework to .NET 5.
My VB source generator doesn't work because of this bug.
The <PropertyGroup>.<IncludePackageReferencesDuringMarkupCompilation> element seems has no effect in VB projects.
The error list of Visual Studio is empty, but there're build errors in the output window. I'm using Visual Studio 16.9 preview 3.

Here's my project: https://github.com/Nukepayload2/MyWpfExtensionGenerator

[Marvin Rühe]

Yes this definitely works like @Zalutskii describes. The new attribute fixes the issue. Turning this on by default is tracked by #3974. So to me (the author of this issue) this is fixed.

Feel free to reopen if issues occur.

[Claire Novotny]

It's also tracked here for the .NET SDK for 5.0.200: dotnet/sdk#15395

[usikpavel]

I'm using VisualStudio 16.8.5, not preview.

In my case the @Zalutskii solution works for simple class generation only, but not for more complicated generator. When I'm trying to apply [AutoNotify] attribute from samples to my ViewModel, then all errors come back again.

UPD. I found a solution here. In addition to <IncludePackageReferencesDuringMarkupCompilation> project option, you must use the .NET 5.0.102 SDK. 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"
  }
}