MarkupCompilePass2 shouldn't zero GeneratedInternalTypeHelper.g.cs

[KirillOsenkov]

This is for .NET Framework but it looks like it might be a problem for .NET Core as well.

Sometimes (and under circumstances unclear to me) MarkupCompilePass2 decides that the internal type helper is not necessary and it zeroes out the file:

wpf/src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks/Microsoft/Build/Tasks/Windows/MarkupCompilePass2.cs

Lines 663 to 687 in 1570c84

	//
	// If no any xaml file with local-types wants to reference an internal type from
	// current assembly and friend assembly, and InternalTypeHelperFile is set in the
	// cache file, now it is the time to remove the content of InternalTypeHelper File.
	//
	// We still keep the empty file to make other parts of the build system happy.
	//
	if (!String.IsNullOrEmpty(_internalTypeHelperFile) && !compilerWrapper.HasInternals)
	{
	if (TaskFileService.Exists(_internalTypeHelperFile))
	{
	// Make empty content for this file.
	MemoryStream memStream = new MemoryStream();
	using (StreamWriter writer = new StreamWriter(memStream, new UTF8Encoding(false)))
	{
	writer.WriteLine(String.Empty);
	writer.Flush();
	TaskFileService.WriteFile(memStream.ToArray(), _internalTypeHelperFile);
	}
	Log.LogMessageFromResources(MessageImportance.Low, SRID.InternalTypeHelperNotRequired, _internalTypeHelperFile);
	}
	}

From what I can see this is a race condition with MarkupCompilePass1 and/or design-time builds which write into the file.

The problem is that the presence or absence of the GeneratedInternalTypeHelper class in the assembly changes its public API. In scenarios where reference assemblies are used for better incremental builds (by setting ProduceReferenceAssembly property to true) this public API change results in a different reference assembly, thus invalidating the entire dependency tree and causing all dependent projects to rebuild unnecessarily.

I'm not entirely certain whether this generated type is really required and when it is actually used, and why is it generated in the first place (nothing in the file looks like it couldn't be in a framework type). But if we are generating it, we should always be generating it deterministically, such that the public API surface doesn't flip flop between having this type and not having it.

See related:
dotnet/msbuild#4217

[KirillOsenkov]

The temporary workaround I came up with that seems to work is just to not include the generated file in the compilation at all:

  <Target Name="Workaround2281"
          AfterTargets="MarkupCompilePass1"
          BeforeTargets="CoreCompile"
          Condition="Exists('$(IntermediateOutputPath)GeneratedInternalTypeHelper.g.cs')">
    <ItemGroup>
      <Compile Remove="$(IntermediateOutputPath)GeneratedInternalTypeHelper.g.cs" />
    </ItemGroup>
  </Target>

  <Target Name="Workaround2281_Part2"
          AfterTargets="MarkupCompilePass2"
          BeforeTargets="CoreCompile"
          Condition="Exists('$(IntermediateOutputPath)GeneratedInternalTypeHelper.g.cs')">
    <ItemGroup>
      <Compile Remove="$(IntermediateOutputPath)GeneratedInternalTypeHelper.g.cs" />
    </ItemGroup>
  </Target>

This seems to work for my project (maybe I'm just getting lucky?).

Also there's certainly something non-deterministic here, as I have two build logs where everything is identical, except one of them clears the file and the other doesn't.

[weltkante]

I've seen cases in the past where the code generated by the TypeHelper was actually used, so unconditionally removing it may introduce bugs if you have code paths which need it. I don't exactly remember what it was, its been years ago, might have been investigating something along the lines of event handlers in styles/templates.

[aolszowka]

My understanding is it was used for Intellisense; specifically the XAML Editor? Does Intellisense still work in that area?

As to why it is getting regenerated; in your cases can you make sure that /obj/ is totally clean? IIRC from my debugging it decided to call into that logic if the cache was determined to be out of date (the cache is generated by using the file names in GetHashCode() and then letting it overflow).

My recollection of our problem was we used MSBuild64 to build via the CLI then opened it up in VS (which used MSBuild32) because GetHashCode() is not the same between different runtime bit-ness the hash would fail causing the Markup pass to run.

[weltkante]

My understanding is it was used for Intellisense; specifically the XAML Editor? Does Intellisense still work in that area?

The .g.i.cs files are for intellisense and are incomplete - the .g.cs files are for building the real assembly and contain the actual generated code which is executed (i.e. you can set breakpoints in them and they'll be hit)