Wpf: Source Generator support for WPF project blocked?

[Marv51]

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.

[jmarolf]

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?

[chsienki]

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: https://github.com/dotnet/roslyn/pull/46669

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

[Marv51]

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.

[jaredpar]

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.

[weltkante]

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.

[jaredpar]

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

Intent is to fix the behavior, not document it.

[Marv51]

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.)

[miloush]

@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

[clairernovotny]

I believe this is a dup of https://github.com/dotnet/wpf/issues/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.

[weltkante]

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.

[Marv51]

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

[jmarolf]

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