dotnet / dotnet/wpf

[WPF .NET 10] Multiple regressions in SDK 10.0.202: Single File crash, folder-name sensitive startup failure, and build error with custom AssemblyName

Open
#11,678 0 comments 0 reactions 0 assignees View on GitHub
Untriaged
Dominant language
C#
Stars
7.7k
Forks
1.3k
Avg merge
1d 11h
Merged PRs (30d)
61

Description

Multiple regressions affect WPF Single File applications on .NET 10 starting
from SDK 10.0.200/10.0.202. All issues are confirmed working on SDK 10.0.103
and 10.0.106.

---

Bug dotnet/sdk#1 — Single File WPF crashes at startup (NotImplementedException in BAML)

First broken SDK: 10.0.200
Last working SDK: 10.0.103

Description
Publishing a WPF app with PublishSingleFile=true causes an immediate crash
at startup. The BAML reader fails to resolve types.

Stack Trace

System.Windows.Markup.XamlParseException: The method or operation is not implemented.
---> System.NotImplementedException
at Baml2006SchemaContext.ResolveBamlType(BamlType bamlType, Int16 typeId)
at Baml2006SchemaContext.GetXamlType(Int16 typeId)
at Baml2006Reader.Process_ElementStart()
...
at System.Windows.Application.DoStartup()

---

Bug dotnet/sdk#2 — Published exe fails to start depending on folder name

First broken SDK: 10.0.202
Last working SDK: 10.0.106

Description
The published Single File exe starts correctly if placed in a folder with a
short/specific name (e.g. beta), but silently dies immediately if the folder
has a different name. No error dialog is shown. The process starts and
terminates instantly.

This is not a MAX_PATH issue — the full path length is well within limits.
The behavior is purely dependent on the folder name, and only with SDK 10.0.202.

Repro

C:\deploy\my-app-name\beta\MyApp.exe ✅ starts correctly
C:\deploy\my-app-name\MyApp.exe ❌ process dies immediately

Notes
• Likely related to how the Single File bundler resolves extraction paths
• Could be related to Bug dotnet/sdk#1 (BAML resolution depends on extraction path)

---

Bug dotnet/sdk#3 — Build error with custom AssemblyName

First broken SDK: 10.0.202
Last working SDK: 10.0.106

Description
Setting a custom equal to the project folder name
causes a build failure:

error: Value cannot be null.
Parameter name: source

The error originates in the XAML markup compiler / code generator.

Repro .csproj
xml

MyCustomName
MyApp

Workaround
None found other than pinning SDK to 10.0.106.

---

Global Workaround for all issues

Pin SDK to 10.0.106 via global.json:

json
{
"sdk": {
"version": "10.0.106",
"rollForward": "disable"
}
}

---

Environment

| SDK broken | 10.0.200, 10.0.202 |
| SDK working | 10.0.103, 10.0.106 |
| Target Framework | net10.0-windows |
| Project Type | WPF, Single File, Self-Contained |
| RuntimeIdentifier | win-x64 |
| OS | Windows 10/11 x64 |
| COM References | Yes (Excel/Office Interop) |

Related

• Previously reported: [WPF Single File publish throws NotImplementedException
in Baml2006SchemaContext.ResolveBamlType]

Contributor guide

Open the contributing guide

Research direction

Reproduce the three WPF cases with SDK 10.0.202 and compare them with 10.0.106, using the supplied project settings and global.json workaround. Start with Baml2006SchemaContext for the startup crash, then inspect the XAML markup compiler/code generator for the custom AssemblyName failure and the Single File extraction-path behavior. Done means the published app starts in either folder, BAML loads, and the custom AssemblyName project builds.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
build-system, desktop
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.