The generated content of GeneratedInternalTypeHelper.g.cs is not stable

[tmat]

Problem description:

Since switching WPF projects in Roslyn repo to Microsoft.NET.Sdk.WindowsDesktop the design time build is failing intermittently.

This is because we use Public API analyzer that checks public API list against a baseline. The public types defined in GeneratedInternalTypeHelper.g.cs are not listed in the baseline, but appear sometimes in the build.

I observed that during command line build GeneratedInternalTypeHelper.g.cs is created with a declaration of class GeneratedInternalTypeHelper and a few moments later it is replaced with an empty file. It seems likely that this sometimes does not happen during design time build.

Actual behavior:

Binary log for the design time build here:
\\mlangfs1\public\jorobich\GenerateInternalTypeHelper

Expected behavior:

The public types are either always generated or never generated.
In addition, I'd expect source file content to not be rewritten during build. An alternative approach to do this is to always generate the code but enclose it in #if. Then you can define a conditional compilation symbol and pass it to the compiler depending on whether the type should be active or not.

Minimal repro:

This is an intermittent issue happening during work in Roslyn.sln.

[rladuca]

This comment seems pertinent here.

wpf/src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks/MS/Internal/MarkupCompiler/MarkupCompiler.cs

Lines 157 to 176 in 76a8e61

	// If the xaml has local references, then it could have internal element & properties
	// but there is no way to determine this until MCPass2. Yet, GeneratedInternalTypeHelper,
	// which is the class that allows access to legitimate internals, needs to be generated
	// in MCPass1. So, to determine if GeneratedInternalTypeHelper.cs needs to be kept or not,
	// MCPass1 & MCPass2 task will use the HasInternals property as indicated below:
	// In pass1, if this property returns true, it will be due to friend internals & so
	// MCPass1 will just decide to keep the file & this property will be ignored in MCPass2
	// if that task is executed as well.
	// In pass1, if this property returns false, MCPass2 will look at this property again after
	// the Xaml Compiler has been called to compile all the local markup files. Now if this
	// property still returns false, the file will be removed, else it will be kept, because
	// this property was true as the xaml compiler encountered local or friend internals
	// during MCPass2.
	// The above will apply only for a clean build, not incremental build.
	public static bool HasInternals
	{
	get { return XamlTypeMapper.HasInternals; }

[rladuca]

Summary of my current understanding:

Markup Compilation Pass 1

• If this is a real build (not intellisense) and a clean build, delete GeneratedInternalTypeHelper.
• MCPass1 will create the GeneratedInternalTypeHelper file if there are internals or local references that can be discerned.

Markup Compilation Pass 2

• The compilation will run and then a decision is made on what to do with the GeneratedInternalTypeHelper file.
  • If the file exists and we have not detected internal references during Pass 2, the file is kept on disk, but the contents are emptied.
  • Otherwise the file is kept as is.

Since an intellisense build does not clean generated files, you can have a situation where the initial intellisense build generates some types, but a subsequent incremental build does not since MCPass2 emptied out the file contents.

[rladuca]

This could be related to the temp project building the same name binary as the real project. We generate the temporary project and compile it in-between MCPass1 and MCPass2. The output assembly is named the same as the normal project's assembly. This temporary assembly will always have a version of GeneratedInternalTypeHelper with actual types inside of it as the decision to empty that file is not made until MCPass2 is over. Subsequently, the actual build of the real project can potentially be done with an emptied version of the file.

We might be able to fix this in the following fashion:

• Change the output path of the temp project
• Ensure PBT ingests this new assembly path as needed
• Ensure that clean targets properly pick up all of the separately created files

If the temporary project was completely separate from the real one (in output as well) we would always generate one assembly with a filled GeneratedInternalTypeHelper and then the real assembly would be consistently generated with or without GeneratedInternalTypeHelper based on MCPass2's result.

The build as is, should be deterministic, but depends on specific knowledge gained during the markup compilation passes. This is fairly opaque to external users. Changing this will give two distinct assemblies that will generally have unvarying inputs regardless of how the build is done.

As is, Roslyn has a workaround for their analyzers, and further issues are theoretical. We can look at this more carefully in the .NET 5 timeframe, putting this on the backlog for now.

[tmat]

@rladuca Thanks for the analysis.

[davkean]

This is a pretty annoying bug; I went to attempt to workaround it by adding it the to the "public API" but then you get the reverse error when its not generated. I've see this popup in 4 separate code bases:

1. Roslyn (http://github.com/dotnet/roslyn)
2. Project System (http://github.com/dotnet/project-system)
3. Editor (internal code base)
4. Common Project System (internal code base).