You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Compile AOT in Windows (dotnet publish -r win-x64 -c Release -o .\publish) : OK
Compile AOT in linux (dotnet publish -r linux-x64 -c Release -o ./publish) : Error
/..../Program.cs(5,4): error CS0121: The call is ambiguous between the following methods or properties: 'ValueStringBuilder.Append(scoped ReadOnlySpan<char>)' and 'ValueStringBuilder.Append(ref ValueStringBuilder.AppendInterpolatedStringHandler)'
in line:
sb.Append($"Test1\n");
Extran info:
.NET SDK:
Version: 9.0.112
Commit: 191254d648
Workload version: 9.0.100-manifests.b3871ecb
MSBuild version: 17.12.50+191254d64
Runtime Environment:
OS Name: ubuntu
OS Version: 22.04
OS Platform: Linux
RID: ubuntu.22.04-x64
Base Path: /usr/lib/dotnet/sdk/9.0.112/
.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.
Host:
Version: 9.0.11
Architecture: x64
Commit: 191254d648
.NET SDKs installed:
9.0.112 [/usr/lib/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 9.0.11 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 9.0.11 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
Interesting - unfortunately I don't have a x64 machine right now at my disposal to verfiy that (on my Mac I can't publish against win-x64 and get errors from clang when targeting linux-arm64 or linux-x64).
What happens if you
a) Update the sdk to the latest patch release of 9.0.x
b) Use net10.0 as target?
The ambiguity around sb.Append($"Test1\n"); likely needs a parser test that distinguishes interpolated strings, escape sequences, and line terminators. A minimal fixture should include normal strings, interpolated strings with no holes, interpolated strings with holes, and verbatim/raw strings if supported. That would prevent a fix for newline escaping from accidentally changing overload or token selection for interpolated strings.
Guess I found the issue (also looking at System.Text.StringBuilder) and the issue stems more from C# 13 and earlier. The basic fix: add a new Append(string?) version just like STB.
We could come around end of year and remove obsolete .net versions and assume C#14 is around
In case you don't want to add those extra overloads, you could alternatively add an [OverloadResolutionPriority] attribute to the ReadOnlySpan<char> overloads. It should be fine as it is though.
In case you don't want to add those extra overloads, you could alternatively add an [OverloadResolutionPriority] attribute to the ReadOnlySpan<char> overloads. It should be fine as it is though.
Good thought - but it wouldn't work with the net8.0 target we still currently have
Good thought - but it wouldn't work with the net8.0 target we still currently have
.NET 8.0 will go out of support on 2026/11/10 (only 4 months from now) so you could remove support for .NET 8.0 (and .NET 9.0) early if you want. Otherwise, we can just continue with your extra method approach. :P
Activity
linkdotnet commentedon Mar 8, 2026
Interesting - unfortunately I don't have a
x64machine right now at my disposal to verfiy that (on my Mac I can't publish againstwin-x64and get errors fromclangwhen targetinglinux-arm64orlinux-x64).What happens if you
a) Update the sdk to the latest patch release of
9.0.xb) Use
net10.0as target?hiSandog commentedon Jul 4, 2026
The ambiguity around
sb.Append($"Test1\n");likely needs a parser test that distinguishes interpolated strings, escape sequences, and line terminators. A minimal fixture should include normal strings, interpolated strings with no holes, interpolated strings with holes, and verbatim/raw strings if supported. That would prevent a fix for newline escaping from accidentally changing overload or token selection for interpolated strings.linkdotnet commentedon Jul 4, 2026
Guess I found the issue (also looking at System.Text.StringBuilder) and the issue stems more from C# 13 and earlier. The basic fix: add a new
Append(string?)version just likeSTB.We could come around end of year and remove obsolete .net versions and assume C#14 is around
linkdotnet commentedon Jul 4, 2026
Release 3.4.2 will be out soon
Joy-less commentedon Jul 4, 2026
In case you don't want to add those extra overloads, you could alternatively add an
[OverloadResolutionPriority]attribute to theReadOnlySpan<char>overloads. It should be fine as it is though.linkdotnet commentedon Jul 4, 2026
Good thought - but it wouldn't work with the
net8.0target we still currently haveJoy-less commentedon Jul 4, 2026
.NET 8.0 will go out of support on 2026/11/10 (only 4 months from now) so you could remove support for .NET 8.0 (and .NET 9.0) early if you want. Otherwise, we can just continue with your extra method approach. :P
linkdotnet commentedon Jul 4, 2026
It will be removed :D don't see a reason having that if we drop old framework versions
Joy-less commentedon Jul 4, 2026
Considering the version 3.4.2 is now released with these overloads, I think they should stay in. No need to drop old framework versions for now.
linkdotnet commentedon Jul 4, 2026
Nono - anyway it would be a major release and I will wait until net8/9 is EOL. So a few more months to go