DotNet 5.0 IdnMapping.GetAscii throws ArgumentException

[HelenMakarchuk]

Description

I wrote an example console application:

1. Get current DotNet version
2. Then get ASCII from latine string (each label equals to or less 63 symbols long, total string length (including dots) is 254 symbols long)

static void Main(string[] args)
{
    Console.WriteLine("Environment.Version: " + Environment.Version);

    new IdnMapping().GetAscii(
        "sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss." +
        "sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss." +
        "sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss." +
        "ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss");

    Console.WriteLine("Hello World!");
}

When I run program on .Net Core 3.1 output is:

Environment.Version: 3.1.13
Hello World!

When I run program on .Net 5.0 output is:

Environment.Version: 5.0.9
Unhandled exception. System.ArgumentException: Decoded string is not a valid IDN name. (Parameter 'unicode')
   at System.Globalization.IdnMapping.IcuGetAsciiCore(String unicodeString, Char* unicode, Int32 count)
   at System.Globalization.IdnMapping.GetAscii(String unicode, Int32 index, Int32 count)
   at System.Globalization.IdnMapping.GetAscii(String unicode, Int32 index)
   at System.Globalization.IdnMapping.GetAscii(String unicode)
   at Program.Main(String[] args)

Are there any breaking changes in DotNet 5 for IdnMapping?
What requirements should be for an input string (characters count, known encoding dependencies, etc)?

Configuration

Version of .NET: 3.1.13, 5.0.9
OS: Windows 10 Enterprise 20H2 (build 19042.1237)
PC Architecture: x64
IDE: Microsoft Visual Studio Community 2019 (version 16.9.2)
Solution platform: ANY CPU

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @tarekgh, @safern
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I wrote an example console application:

1. Get current DotNet version
2. Then get ASCII from latine string (each label equals to or less 63 symbols long, total string length (including dots) is 254 symbols long)

static void Main(string[] args)
{
    Console.WriteLine("Environment.Version: " + Environment.Version);

    new IdnMapping().GetAscii(
        "sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss." +
        "sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss." +
        "sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss." +
        "ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss");

    Console.WriteLine("Hello World!");
}

When I run program on .Net Core 3.1 output is:

Environment.Version: 3.1.13
Hello World!

When I run program on .Net 5.0 output is:

Environment.Version: 5.0.9
Unhandled exception. System.ArgumentException: Decoded string is not a valid IDN name. (Parameter 'unicode')
   at System.Globalization.IdnMapping.IcuGetAsciiCore(String unicodeString, Char* unicode, Int32 count)
   at System.Globalization.IdnMapping.GetAscii(String unicode, Int32 index, Int32 count)
   at System.Globalization.IdnMapping.GetAscii(String unicode, Int32 index)
   at System.Globalization.IdnMapping.GetAscii(String unicode)
   at Program.Main(String[] args)

Are there any breaking changes in DotNet 5 for IdnMapping?
What requirements should be for an input string (characters count, known encoding dependencies, etc)?

Configuration

Version of .NET: 3.1.13, 5.0.9
OS: Windows 10 Enterprise 20H2 (build 19042.1237)
PC Architecture: x64
IDE: Microsoft Visual Studio Community 2019 (version 16.9.2)
Solution platform: ANY CPU

Author:	HelenMakarchuk
Assignees:	-
Labels:	area-System.Globalization, untriaged
Milestone:	-

[tarekgh]

@HelenMakarchuk in .NET 5.0 we have switched to use ICU library. In .NET 3.1 we were using the native Windows NLS APIs for IDN. you can learn more about this change in the doc.

Looking at the case in your repro, looks the length of the string is what is causing the failure. If I remove just one character from the end of the string, it will succeed. if you want to go back to old behavior (which we don't recommend doing that as ICU behavior is more correct), you may follow this instructions. Let me know if you need any more help if you are blocked.

[tarekgh]

I confirmed that ICU is failing the call with the info error UIDNA_ERROR_DOMAIN_NAME_TOO_LONG because of the length.

[HelenMakarchuk]

Thank you for the detailed answer