`dotnet run` gives `ArgumentOutOfRangeException` error at `TryGetTargetArchitecture` method
See original GitHub issueDescribe the bug
I installed .NET 6.0.1 SDK, and turned out that I cannot use command dotnet run
at all, because it keeps giving me ArgumentOutOfRangeException
. However, it is successful to run dotnet build
then dotnet [path-to-dll]
or dotnet watch run
instead.
The full error message:
System.ArgumentOutOfRangeException: startIndex cannot be larger than length of string. (Parameter 'startIndex')
at System.String.Substring(Int32 startIndex, Int32 length)
at Microsoft.DotNet.Tools.Run.RunCommand.TryGetTargetArchitecture(String runtimeIdentifier, Nullable`1& targetArchitecture)
at Microsoft.DotNet.Tools.Run.RunCommand.GetTargetCommand()
at Microsoft.DotNet.Tools.Run.RunCommand.Execute()
at Microsoft.DotNet.Tools.Run.RunCommand.Run(String[] args)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)
at Microsoft.DotNet.Cli.Program.Main(String[] args)
I have tried reinstalled using SDK Installer, Visual Studio Installer, and binaries zip file. All gave me the same result.
So I decided to pull the branch release/6.0.1xx
from this repository, and modified the method TryGetTargetArchitecture
in file src\Cli\dotnet\commands\dotnet-run\RunCommand.cs
to add try&catch blocks as following to debug the behaviour of the command:
private static bool TryGetTargetArchitecture(string runtimeIdentifier, out Architecture? targetArchitecture)
{
targetArchitecture = null;
int separator = runtimeIdentifier.LastIndexOf("-");
if (separator < 0)
{
return false;
}
try // ↓ MODIFIED FROM HERE
{
targetArchitecture = runtimeIdentifier.Substring(separator + 1).ToLowerInvariant() switch
{
"arm" => Architecture.Arm,
"arm64" => Architecture.Arm64,
"x64" => Architecture.X64,
"x86" => Architecture.X86,
_ => null
};
}
catch
{
Console.WriteLine($"runtimeIdentifier = {runtimeIdentifier}");
Console.WriteLine($"runtimeIdentifier.Length = {runtimeIdentifier.Length}");
Console.WriteLine("runtimeIdentifier (CharArray) = " + String.Join(", ", runtimeIdentifier.ToCharArray().Select(x => $"'{x}'")));
Console.WriteLine($"separator = {separator}");
} // ↑ MODIFIED UNTIL HERE
return targetArchitecture != null;
}
Here is the result:
runtimeIdentifier =
runtimeIdentifier.Length = 0
runtimeIdentifier (CharArray) =
separator = 0
runtimeIdentifier = win-x64
runtimeIdentifier.Length = 7
runtimeIdentifier (CharArray) = 'w', 'i', 'n', '-', 'x', '6', '4'
separator = 7
Oddly, it seems that String.LastIndexOf
in my machine does not work as expected, and that cause it returns an incorrect character index.
I don’t know what in my machine breaks the LastIndexOf
, but it would be better if we have a safer logic in this method to prevent the similar problem.
Further technical details
- Include the output of
dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.100
Commit: 9e8b04bbff
Runtime Environment:
OS Name: Windows
OS Version: 10.0.22000
OS Platform: Windows
RID: win10-x64
Base Path: C:\Users\xxx\exe\dotnet\sdk\6.0.100\
Host (useful for support):
Version: 6.0.0
Commit: 4822e3c3aa
.NET SDKs installed:
6.0.100 [C:\Users\xxx\exe\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.0 [C:\Users\xxx\exe\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0 [C:\Users\xxx\exe\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.0 [C:\Users\xxx\exe\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:15 (5 by maintainers)
Top GitHub Comments
We should take the suggested fix as soon as possible - RIDs should always be parsed/manipulated in Invariant ways in the SDK. I’ve marked the issue as up-for-grabs if anyone from the community would like to contribute it. Tests would need to demonstrate that this function works for several different cultures set as the CurrentCulture/CurrentUICulture, ideally including several of those that use non-ASCII character sets, and some that use right-to-left encodings.
This issue still present as of .NET version 7.0.306. Might be time to reopen this up. i’m still not sure how much this would affect my workflow. Let’s hope for a minimal effect long-terms wise . I’m also Thai. So this issue must be something related to our localization encoding?