Building with SDK 8.0.403 unexpectedly generates WinRT-related code

[chris-white-wtw]

Describe the bug

After updating the .NET SDK from 8.0.402 to 8.0.403, some projects that target net8.0-windows10.0.19041.0 have started generating unexpected WinRT-related code via source generator WinRT.SourceGenerator.

The generated code uses language features only available in C# 9+, which in this case causes compilation to fail, but the main issue is that this source generator generates anything at all: this is not a project that uses WinRT, and with SDK 8.0.402 this doesn't happen.

Additionally, we are seeing diagnostics CsWinRT1028 and CsWinRT1030, which we do not see with 8.0.402.

To Reproduce

See https://github.com/chris-white-wtw/dotnet-sdk-winrt-issue.

Using SDK 8.0.403, build test.csproj.

Exceptions (if any)

No exceptions, just a compilation error:

C:\git\dotnet-sdk-winrt-issue\test\obj\Debug\net8.0-windows10.0.19041.0\generated\WinRT.SourceGenerator\Generator.WinRT
AotSourceGenerator\WinRTGlobalVtableLookup.g.cs(11,10): error CS8370: Feature 'module initializers' is not available in
 C# 7.3. Please use language version 9.0 or greater. [C:\git\dotnet-sdk-winrt-issue\test\test.csproj]

Further technical details

dotnet --info:

.NET SDK:
 Version:           8.0.403
 Commit:            c64aa40a71
 Workload version:  8.0.400-manifests.18f19b92
 MSBuild version:   17.11.9+a69bbaaf5

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64
 Base Path:   c:\work\dotnet\dotnet\sdk\8.0.403\

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: VS 17.10.35013.160
   Manifest Version:    8.0.0-preview.1.23557.2/8.0.100
   Manifest Path:       c:\work\dotnet\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.0-preview.1.23557.2\WorkloadManifest.json
   Install Type:        FileBased


Host:
  Version:      8.0.10
  Architecture: x64
  Commit:       81cabf2857

.NET SDKs installed:
  8.0.403 [c:\work\dotnet\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.10 [c:\work\dotnet\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.10 [c:\work\dotnet\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.10 [c:\work\dotnet\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  C:\git\dotnet-sdk-winrt-issue\global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

No particular IDE - running from command line.

[AliveDevil]

Related: https://github.com/microsoft/CsWinRT/blob/2.1.5.241003.1/nuget/Microsoft.Windows.CsWinRT.targets#L21

Set <CsWinRTAotOptimizerEnabled> to false.

[chris-white-wtw]

Thanks @AliveDevil, I can confirm that setting this property works around the issue for our affected projects

[27k1]

I can confirm this fix works

[Balkoth]

So what's the deal here? Is it ok to disable the optimizer or should the warnings be fixed? Why is this enabled by default even when no other trimmer option is enabled in the project? And how many of those trimmer options is dotnet going to introduce? There are already so many that no one can remember them.

[AliveDevil]

Hopefully, they'll make this Opt-In to all the interfaces you want exposed to WinRT/AOT: https://github.com/microsoft/CsWinRT/issues/1814

[rjsams]

CsWinRT1028 is being generated for simple classes. Ex: Create an empty class, implement IDispose, and the warning will be generated. IMO, foundational interfaces should not be triggering this.

Neither AOT nor trimming was enabled in that test case.

[thirstyape]

The fix by @AliveDevil worked for me too.

For others, I saw this issue in another variety, error logs were not clear, as with the original post WinRTGlobalVtableLookup.g.cs was mentioned.

~\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs(5,20): error CS0116: A namespace cannot directly contain members such as fields, methods or statements [~\my_project.csproj::TargetFramework=net8.0-windows10.0.19041.0]
~\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs(5,29): error CS0116: A namespace cannot directly contain members such as fields, methods or statements [~\my_project.csproj::TargetFramework=net8.0-windows10.0.19041.0]
~\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs(5,19): error CS1514: { expected [~\my_project.csproj::TargetFramework=net8.0-windows10.0.19041.0]
~\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs(5,28): error CS1022: Type or namespace definition, or end-of-file expected [~\my_project.csproj::TargetFramework=net8.0-windows10.0.19041.0]
~\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs(6,1): error CS1022: Type or namespace definition, or end-of-file expected [~\my_project.csproj::TargetFramework=net8.0-windows10.0.19041.0]

[paulpv]

Posting this to hopefully help others that start seeing this.

I am not certain of the OP issue, but on a relatively simple personal hobby project I am working on I started to see these error when compiling:

Type	Code	Description	File	Line
Error	CS0116	A namespace cannot directly contain members such as fields, methods or statements	obj\Debug\net8.0-windows10.0.26100.0\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs	5
Error	CS1022	Type or namespace definition, or end-of-file expected	obj\Debug\net8.0-windows10.0.26100.0\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs	6
Error	CS1514	{ expected	obj\Debug\net8.0-windows10.0.26100.0\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs	5

My C# WinForms app and libs do not explicitly use WinRT (they do pinvoke some user32.dll calls).

I found this issue and then https://github.com/microsoft/CsWinRT/issues/1814.

I edited my .csproj file to add CsWinRTAotOptimizerEnabled as follows:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net8.0-windows10.0.26100.0</TargetFramework>
    ...
    <CsWinRTAotOptimizerEnabled>false</CsWinRTAotOptimizerEnabled>
  </PropertyGroup>
...

The problem went away.

I changed CsWinRTAotOptimizerEnabled to true.

The problem came back.

I will be leaving CsWinRTAotOptimizerEnabled set to false.

[ekalchev]

None of the proposed solution in the linked issues doesn't work for me. The only thing that worked was to uninstall .net sdk 8.0.403

[awakecoding]

Same as @ekalchev here - the issue occurs with .NET SDK 8.0.403, and I double checked with a diagnostic build log that CsWinRTAotOptimizerEnabled was properly set to false, it simply has no effect: the WinRT source generator keeps getting called, wasting a good 30 seconds doing nothing useful in our builds. This commit between 8.0.402 and 8.0.403 appears to be the relevant: https://github.com/dotnet/sdk/commit/ec0ad19377bc77ea1d394220bd6a76c01191341d

[baronfel]

Tagged @Sergio0694 and @manodasanW for follow-up - Sergio said this should be fixed soon but they may have more details.

[awakecoding]

Is there a temporary hack? I literally edited C:\Program Files\dotnet\sdk\8.0.403\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Windows.targets to first comment out the potentially offending line, then decided to just explicitly set <CsWinRTAotOptimizerEnabled>false</CsWinRTAotOptimizerEnabled>, and guess what? The WinRT source generator still gets called in our builds. This tells me that the bug could be in Microsoft.Windows.SDK.NET.Ref which is supposed to consume the CsWinRTAotOptimizerEnabled variable, but I have no idea where the right files to locally modify are.

[awakecoding]

We found a temporary hack. We've explicitly removed the Microsoft.Windows.SDK.NET.Ref framework reference in one of our core csproj files by adding this:

<ItemGroup>
	<FrameworkReference Remove="Microsoft.Windows.SDK.NET.Ref" />
</ItemGroup>

Since we apparently don't need Microsoft.Windows.SDK.NET.Ref and it was getting added automatically, removing it works around the issue entirely. CsWinRTAotOptimizerEnabled does seem to be set to false properly, but Microsoft.Windows.SDK.NET.Ref appears to be ignoring it.

[Sergio0694]

Why did you have to do this? Was setting CsWinRTAotOptimizerEnabled to false not working in your project?

[awakecoding]

Why did you have to do this? Was setting CsWinRTAotOptimizerEnabled to false not working in your project?

Exactly, setting CsWinRTAotOptimizerEnabled to false has no effect, we've tried every way possible, enabled diagnostic logging to ensure it was set to false, and even went as far as modifying Microsoft.NET.Windows.targets directly to force it to false. Our conclusion is that CsWinRTAotOptimizerEnabled is simply ignored by Microsoft.Windows.SDK.NET.Ref

[ekalchev]

I can confirm that settings CsWinRTAotOptimizerEnabled = false on the project that emit the error doesn't help

[ekalchev]

To work around this issue, I initially uninstalled .NET SDK 8.0.403. However, when I set up a new development machine with a fresh Visual Studio installation, it automatically installed the latest SDK, which is 8.0.403. This led to the same build issue. Unfortunately, I cannot uninstall SDK 8.0.403 this time because it was installed via Visual Studio. Windows requires uninstallation through the Visual Studio Installer, but this process tries to remove all dependent components, including .NET Desktop Development. Essentially, there is no workaround for a new Visual Studio installation. I have been struggling with this for two days and am out of ideas on how to resolve it.

[ekalchev]

For the people like me that cannot uninstall SDK 8.0.403. Here workaround I found.

	<Target Name="DisableWinRTSourceGenerator" BeforeTargets="CoreCompile">
		<ItemGroup>
			<Analyzer Remove="@(Analyzer)"
					  Condition="'%(FileName)%(Extension)' == 'WinRT.SourceGenerator.dll'"/>
		</ItemGroup>
	</Target>

[awakecoding]

Has this been acknowledged as an issue by anybody from Microsoft yet? We're quite a few people that can confirm this really is an issue, and workarounds are required to regain build performance. @Sergio0694

[ekalchev]

@awakecoding, @baronfel from Microsoft is looking at this. He asked me for logs. See my response in the other issue here https://github.com/dotnet/sdk/issues/44145

[abbweiman]

Any update on this? I'm getting CS0436, CsWinRT1028, CS0618 and CS0108 errors when opening a project using CsWinRT that has worked fine earlier.

[manodasanW]

@abbweiman What version of CsWinRT are you using? Can you try the latest version on NuGet? Also, do you happen to have a reference (direct or transitive) to WinAppSDK? If so, can you try the latest version for that too.

Most of the known issues discussed in this bug are resolved in CsWinRT 2.2.0 which I expect should be the default in next month's .NET SDK servicing update.

[abbweiman]

@manodasanW Ah yes, it works after upgrading to 2.2.0. Thanks.

[DamianSuess]

Any word on how to address this with .NET MAUI?

[df-pkoopmann]

This bug seems to be fixed with dotnet SDK version 9.0.103. I couldn't find any release notes regarding it being fixed. But according to my tests, WinRT dependencies were still implicitly added with version SDK version 9.0.100 and aren't added anymore with version 9.0.103.

I would still like to know if this was intentional or not, but I'm glad that its seemingly fixed nonetheless.

[rufw91]

Any word on how to address this with .NET MAUI?

<CsWinRTAotOptimizerEnabled>false</CsWinRTAotOptimizerEnabled>