When UseWPF set True in a WinForms. Proj fails to recognize ApplicationConfiguration bootstrap code

[Njoro007]

.NET version

6.0.3

Did it work in .NET Framework?

Yes

Did it work in any of the earlier releases of .NET Core or .NET 5+?

Worked without any issues in NET 5 and Net Framework

Issue description

In a WinForms desktop application targeting .NET 6, the [UseWindowsForms] element in the .proj file is set to True, and a bootstrap ApplicationConfiguration.Initialize(); is generated and called from the startup file Program.

Now I want to enable WPF by setting [EnableWPF] to True. When I do that and build I get the following error in the output log

Program.cs(13,13,13,37): error CS0103: The name 'ApplicationConfiguration' does not exist in the current context 1>Done building project "WinFormsApp1_s2dcxfug_wpftmp.csproj" -- FAILED.

My workaround for a net6 WinForm Project with WPF Enabled is editing the Program.CS to code below
//ApplicationConfiguration.Initialize(); Application.SetHighDpiMode(HighDpiMode.SystemAware); Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1());

Steps to reproduce

To Reproduce

• Create a new Windows Forms project in VS 2022 targeting .NET 6.
• Go to proj properties and check the Enable WPF for this project check box
• Add a WPF window to the project
• Build

[dreddy-work]

@RussKie, can you take a look at this?

[RussKie]

@Njoro007 please provide a simple repro that manifest the issue.

[Njoro007]

To Reproduce

• Create a new Windows Forms project in VS 2022 targeting .NET 6.

• Go to Application/Proj Properties, under Application check the Enable WPF for this project check box

• Add a WPF window to the project

• and then Build. (Error will show)

[RussKie]

I am unable to repro it.

[Njoro007]

Added a WPF Window/Page?...I have done a recording

rec-screen.mp4

[RussKie]

Thank you for the video. I can repro it now.

[RussKie]

I've looked through the binlog, and there's a second compilation pass for a temp WPF project:

I guess the Windows Forms source generator isn't run for the temp project, and the temp project can't resolve ApplicationConfiguration.Initialize() call, and this is the cause of the failure.

The Windows Forms SG generates the body of ApplicationConfiguration.Initialize(), but we don't emit it in a form a file, and hence we can't pass it on to the WPF temp project for a compilation.
https://github.com/dotnet/winforms/blob/c402e2a21cc3d6ab1c3fe6209ff829361aa596b9/src/System.Windows.Forms.Analyzers.CSharp/src/System/Windows/Forms/Generators/ApplicationConfigurationGenerator.cs#L50

@sharwell @chsienki @jmarolf I think I need you help here.

• How can I check/determine whether the Windows Forms SG is run by the temp project?
• Can we save ApplicationConfiguration.g.cs as fie? I tried adding <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> to the SG, but it didn't seem to help - I still couldn't see the file.

Thanks

[chsienki]

Hmm, we've seen this problem in a few different iterations.

dotnet/roslyn#60257
#4421
dotnet/roslyn#46300

Basically all of these occur because the 'inner build' isn't including the required source generators. I think it was generally fixed for WPF, but my best guess is that the winforms generator is somehow being conditionally included on the <UseWinForms> project property and the temp WPF project doesn't have that set.

[chsienki]

@RussKie Yeah, the ResolveTargetingPackAssets target isn't getting run by the WPF inner build, so the winforms generator never gets picked up by that build. I'd suggest starting with WPF to see why that isn't run / if it can be.

[RussKie]

Our source generator is only included for Windows Forms apps:
https://github.com/dotnet/winforms/blob/8e757eb35354dd9f0d6297ff721dd2c1f773b59d/pkg/Microsoft.Private.Winforms/sdk/dotnet-windowsdesktop/System.Windows.Forms.FileClassification.props#L13-L14
C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\<version>\data\FrameworkList.xml is then generated from this list, which is then used by ResolveTargetingPackAssets target to resolve what analyzers need to be included for a project.
I don't believe it'd be right to include Windows Forms specific source generators and analyzer for a WPF application.

My thinking is though along the lines of that the source generated content should be present on disk, so it can be included in the compilation process. In a way similar to other generated (though not source generated) files, e.g., obj\Debug\net6.0-windows\<project name>.AssemblyInfo.cs or obj\Debug\net6.0-windows\<project name>.GlobalUsings.g.cs.

[RussKie]

Here's a binlog from a basic Windows Forms app with a WPF window.

Upon further digging in I've started thinking that perhaps the issue is caused by GenerateTemporaryTargetAssembly, that is not aware of inbox analyzers (described in https://github.com/dotnet/designs/blob/main/accepted/2021/InboxSourceGenerators.md) and introduced in .NET 6.0 timeframe:

wpf/src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks/Microsoft.WinFX.targets

Lines 439 to 455 in bedefb0

	<GenerateTemporaryTargetAssembly
	CurrentProject="$(MSBuildProjectFullPath)"
	MSBuildBinPath="$(MSBuildBinPath)"
	ReferencePathTypeName="ReferencePath"
	CompileTypeName="Compile"
	GeneratedCodeFiles="@(_GeneratedCodeFiles)"
	ReferencePath="@(ReferencePath)"
	BaseIntermediateOutputPath="$(BaseIntermediateOutputPath)"
	IntermediateOutputPath="$(_IntermediateOutputPathNoTargetFrameworkOrRID)"
	AssemblyName="$(AssemblyName)"
	CompileTargetName="$(_CompileTargetNameForLocalType)"
	GenerateTemporaryTargetAssemblyDebuggingInformation="$(GenerateTemporaryTargetAssemblyDebuggingInformation)"
	IncludePackageReferencesDuringMarkupCompilation="$(IncludePackageReferencesDuringMarkupCompilation)"
	Analyzers="$(Analyzers)"
	TemporaryTargetAssemblyProjectName="$(_TemporaryTargetAssemblyProjectName)"
	MSBuildProjectExtensionsPath="$(MSBuildProjectExtensionsPath)"
	>

Curiously, the task contains this line:

wpf/src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks/Microsoft.WinFX.targets

Line 452 in bedefb0

Analyzers="$(Analyzers)"

...however, it is a property and generates a property in the temp project, and it has nothing to do with the list of resolved analyzers, which is contained in @Analyzer item group.

[ThomasGoulet73]

I can reproduce the bug on my machine using the Regex source generator so this is unrelated to WinForms.

@RussKie The code snippet for Analyzers that you sent looks suspicious, GenerateTemporaryTargetAssembly should use the Analyzer ItemGroup to add it in the generated csproj to pass to the Csc task in CoreCompile (Which also uses the Analyzer ItemGroup).

I'll try to work on a fix (If you're not already working on one).

[RussKie]

Hmm, we've seen this problem in a few different iterations.

dotnet/roslyn#60257
#4421
dotnet/roslyn#46300

@ThomasGoulet73 do you think your fix would address any of these?

[ThomasGoulet73]

@RussKie Here's the result of my tests:

dotnet/roslyn#60257
Fixed by my PR. I tried the repro and the build fails without my changes and succeeds with my changes.

#4421
Not fixed by my PR. It looks like #5711 (It looks like SomeRazorComponent is generated in the generated project namespace instead of the main project namespace. WpfBlazorRepro_5s0cnboz_wpftmp instead of WpfBlazorRepro), I'll try to take a closer look at #5711.

dotnet/roslyn#46300
Looks unrelated to WPF, the issue talks about WinUI 3 and the CompileXaml task, which is not in WPF.

[ThomasGoulet73]

#4421 Not fixed by my PR. It looks like #5711 (It looks like SomeRazorComponent is generated in the generated project namespace instead of the main project namespace. WpfBlazorRepro_5s0cnboz_wpftmp instead of WpfBlazorRepro), I'll try to take a closer look at #5711.

I found the problem, I opened #6535.

[RussKie]

Champion! Thank you

[RussKie]

@singhashish-wpf can we expedite this? This needs to be serviced into .NET 6.
/cc: @merriemcgaw