Design-time build (DesignTimeBuild=true) fails with NETSDK1022 duplicate Compile ('.g.cs') in the _wpftmp project on .NET 10 SDK when XAML references a same-project type

[anagnorisis2peripeteia]

Description

On the .NET 10 SDK, running MSBuild with -p:DesignTimeBuild=true on a WPF project whose XAML references a same-project type fails with:

Microsoft.NET.Sdk.DefaultItems.Shared.targets(190,5): error NETSDK1022: Duplicate 'Compile' items were included. The .NET SDK includes 'Compile' items from your project directory by default. ... The duplicate items were: '...\obj\Debug\net8.0-windows\LocalControl.g.cs'; '...\obj\Debug\net8.0-windows\GeneratedInternalTypeHelper.g.cs' [...\WpfLib_xxxxx_wpftmp.csproj]

The error is raised from the temporary markup-compile project (*_wpftmp.csproj, i.e. the GenerateTemporaryTargetAssembly pass) — the generated .g.cs files end up in its Compile items twice. The same command succeeds on the .NET 8 SDK, succeeds on the 10 SDK without the property, and a normal (non-design-time) build succeeds on both.

This breaks design-time analysis tooling generally: I hit it via Stryker.NET/Buildalyzer, whose project analysis performs an instrumented design-time build (see stryker-mutator/stryker-net#3701 for the investigation trail).

Reproduction Steps

WpfLib/WpfLib.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
</Project>

WpfLib/MyConverter.cs:

using System; using System.Globalization; using System.Windows.Data;
namespace WpfLib
{
    public class MyConverter : IValueConverter
    {
        public object Convert(object v, Type t, object p, CultureInfo c) => v;
        public object ConvertBack(object v, Type t, object p, CultureInfo c) => v;
    }
}

WpfLib/LocalControl.xaml (the key part — it references the local type, which triggers the temp-assembly pass):

<UserControl x:Class="WpfLib.LocalControl"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:WpfLib">
  <UserControl.Resources>
    <local:MyConverter x:Key="conv"/>
  </UserControl.Resources>
  <TextBlock Text="{Binding Converter={StaticResource conv}}"/>
</UserControl>

WpfLib/LocalControl.xaml.cs:

using System.Windows.Controls;
namespace WpfLib { public partial class LocalControl : UserControl { public LocalControl() { InitializeComponent(); } } }

Then:

dotnet msbuild WpfLib\WpfLib.csproj /restore /t:Clean;Build -p:DesignTimeBuild=true

Expected behavior

The design-time build succeeds (as it does on the .NET 8 SDK), or at least does not double-include the WPF-generated .g.cs files in the temporary project.

Actual behavior

error NETSDK1022: Duplicate 'Compile' items for LocalControl.g.cs and GeneratedInternalTypeHelper.g.cs, raised in WpfLib_*_wpftmp.csproj; exit code 1.

Regression?

Yes. The identical project and command succeed on SDK 8.0.420; they fail on SDK 10.0.301.

Additional data points:

• Only reproduces when the XAML references a local (same-project) type — with only package/framework xmlns references (no temp-assembly pass), the design-time build succeeds.
• DesignTimeBuild=true alone is sufficient; I bisected the full property set a design-time analyzer (Buildalyzer) passes, one property at a time, and every other property is innocent.
• DefaultItemExcludes in the failing build correctly contains obj\** for the real project; the duplication happens in the temp project's context.

Known Workarounds

Pin the .NET 8 SDK via global.json for the analysis run, or avoid the design-time property set (a normal build is unaffected).

Impact

Any tool that performs design-time builds of WPF projects (Buildalyzer, Stryker.NET, and similar analyzers) fails on .NET 10 SDK for projects with local-type XAML references.

[lindexi]

Seems like there are already a bunch of related issues reported for this. I think the best way forward would be using a Source Generator.

[anagnorisis2peripeteia]

Thanks @lindexi. Agreed that the Roslyn source-generator rewrite (#6974) is the right long-term fix — it removes the temporary markup-compile project (GenerateTemporaryTargetAssembly) entirely, which is the common root here and in the related temp-project issues (#3421, #9524).

One thing worth flagging for prioritisation independent of that timeline: this particular failure looks like a fresh regression in the .NET 10 SDK, not long-standing behaviour — the identical project and design-time command succeed on 8.0.420 and fail only on 10.0.301 (repro in the issue). Because it fails a plain design-time build, it silently breaks any design-time analysis tooling on WPF projects with local-type XAML today (I hit it via Buildalyzer/Stryker.NET). Happy to consolidate under a canonical issue if you'd prefer one — just point me at it.

[lindexi]

@anagnorisis2peripeteia I think this is the new issues if fail only on 10.x version.

[anagnorisis2peripeteia]

Possible root cause — a design-time build change in the .NET 10 WPF targets

I think I've traced this to a single change in the WPF build logic that ships with the SDK (Microsoft.NET.Sdk.WindowsDesktop's Microsoft.WinFX.targets). One condition gained Or '$(DesignTimeBuild)' == 'true':

<!-- .NET 8 -->  <CoreCompileDependsOn Condition="'$(BuildingInsideVisualStudio)' == 'true'">
<!-- .NET 10 --> <CoreCompileDependsOn Condition="'$(BuildingInsideVisualStudio)' == 'true' Or '$(DesignTimeBuild)' == 'true'">

On .NET 8 that markup-compilation step only ran inside Visual Studio. On .NET 10 it also runs for a plain (command-line) design-time build. The knock-on effect: WPF now generates the XAML code-behind files (*.g.cs) earlier in the process — before it builds its temporary markup-compile project. By the time that temporary project is generated, those .g.cs files already exist, and the temporary project ends up listing each of them twice — once explicitly, and once via the SDK's automatic "include everything" file collection — which is what trips NETSDK1022: Duplicate 'Compile' items.

What points to this:

• Reverting only that one line makes the design-time build succeed again. Reverting the other line that changed in the same file has no effect.
• The duplicate error names exactly the two generated files (LocalControl.g.cs, GeneratedInternalTypeHelper.g.cs), and it comes from the temporary *_wpftmp project.
• Turning off the SDK's automatic file inclusion (EnableDefaultCompileItems=false), or removing the two explicit entries, makes the duplicate go away.
• Same project builds fine on SDK 8.0.420 and fails only on 10.0.301.

One caveat I want to be upfront about: I couldn't fully explain why the SDK's normal "ignore the obj folder" rule doesn't already prevent the duplicate here — so I'm flagging this as a likely cause, not a certainty. The cleanest fix (guard that condition for the local-type path, or stop the temporary project from listing the generated files twice) is really your call since you know the intent behind the original change. Happy to open a PR if a direction looks right.

[anagnorisis2peripeteia]

On @lindexi's earlier point about #6974 — yes, the Roslyn source-generator rewrite would remove this class of problem entirely, not just this instance. This failure lives inside the GenerateTemporaryTargetAssembly / *_wpftmp.csproj mechanism, which #6974 replaces outright (and, as noted there, removes the *_wpftmp.csproj files). With the generated code produced in-compilation instead of written to obj and re-compiled via a temporary project, there'd be no separately-generated files for a temporary project to double-count — so NETSDK1022 here couldn't arise.

That said, #6974 is a larger rewrite, and this is a live regression on 10.x that breaks command-line design-time builds (and the analysis tooling that relies on them) today. So a small targeted fix in the meantime still seems worthwhile — happy to help with that.

[lindexi]

@anagnorisis2peripeteia PR welcome.