Satellite assemblies for three-letter languages are not copied from NuGet package

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Satellite assemblies for cultures with three-letter language codes, like “sma-NO” with “Sami, Southern (Norway)” provided in an NuGet package are not copied to the build output directory as two-letter language code cultures as “nb-NO” with “Norwegian Bokmål (Norway)” are. The three-letter language code satellite assembly is included in the NuGet package, and is located in the expected “sma-NO” subdirectory, next to two-letter language code satellite assemblies:

.nuget\packages\package.name\1.1.8\lib\netstandard2.0

When referencing projects within the same solution, without the use of a NuGet package, three-letter language code satellite assemblies are copied to the output directory as expected.

This issue has been observed over time with VS 17.3.x and is still not working with 17.4.1.

---

I can repro this issue.

See original VSissue for repro steps and code.

[nkolev92]

Code affected is https://github.com/NuGet/NuGet.Client/blob/84d99ce064a5f70628c89af9f30693581e84dc37/src/NuGet.Core/NuGet.Packaging/ContentModel/ManagedCodeConventions.cs#L143-L164.

[MarkIvanDev]

This is still a problem even for NuGet packages like Humanizer that has support for the fil-PH Filipino (Philippines) locale.

[baronfel]

I took a look at all of the cultures available in .NET (via CultureInfo.GetCultures(CultureTypes.AllCultures) |> Seq.map (fun c -> c.IetfLanguageTag.IndexOf '-') |> Seq.distinct;;) and all of them either have no -, or a - at the second or third position (meaning that two-letter and three-letter culture prefixes are all that's in use. So I think the code that @nkolev92 pointed at could be changed with a small tweak to check if name[2] or name[3] was a - character and we'd be good for a while.

The correct but probably slowest fix might be to check if the culture name in question is known to .NET via the CultureInfo APIs, but those throw exceptions if the culture isn't known, and they also don't provide a 'tryCreatecultureInfo'-style API to prevent throwing.

[nkolev92]

I like the simple fix.

If we wanted to do the CultureInfo APIs, we can probably just statically initialize a dict with all cultures at the first call, but that seems like an overkill, given that as far as NuGet is concerned, all culture checks are string matches and nothing more.