[Bug]: dotnet build excludes some embedded files

[bhaeussermann]

Issue Description

Some names of embedded files cause them to not be embedded into the built dll when building the project using dotnet build. However, when building using Visual Studio or msbuild the embedded file is included.

A file that will be excluded is one whose name ends in something like 1.X-A.txt

Steps to Reproduce

Showing that it works via msbuild

• Change to the directory of the project.
• Run dotnet restore
• Run msbuild
• Run the built exe: bin\Debug\net6.0\EmbeddedResourceNotFound.exe

The program prints the contents of the embedded file as expected.

Fails via dotnet build

• Clean: dotnet clean
• Build: dotnet build
• Run the built exe: bin\Debug\net6.0\EmbeddedResourceNotFound.exe

The program fails with

Unhandled exception. System.Exception: Resource [EmbeddedResourceNotFound.Resources.1.X-A.txt] not found.

EmbeddedResourceNotFound.zip

Expected Behavior

dotnet build should produce a binary that correctly embeds the file regardless of the file name.

Actual Behavior

dotnet build does not include the embedded file into the binary if its name ends in something like 1.X-A.txt

Analysis

No response

Versions & Configurations

No response

[jrdodds]

I replicated the issue with the example code.

When I first built the example project as provided, I noticed that a satellite resource assembly is generated in an X-A sub-directory.

I added a 1.Y-B.txt file in the project directory and set it as an embedded resource. I also added a hello.txt file in the Resources sub-directory and set it as an embedded resource.

  <ItemGroup>
    <EmbeddedResource Include="Resources\1.X-A.txt" />
    <EmbeddedResource Include="1.Y-B.txt" />
    <EmbeddedResource Include="Resources\hello.txt" />
  </ItemGroup>

The 1.Y-B.txt and hello.txt files are embedded in the EmbeddedResourceNotFound.dll as expected.

X-A resembles a CultureInfo name. My guess is that a file in a sub-directory (I tested renaming Resources and adding a sub-directory under Resources) with a name ending in what resembles a CultureInfo name and a file extension is being treated as a localized resource.

The work-around is to either move 1.X-A.txt to the project folder or rename the file so that the name doesn't resemble a CultureInfo name.

As to how and why the behavior is different between msbuild and dotnet msbuild -- I don't know. I did observe that on macOS -p:GenerateSatelliteAssembliesForCore=false will cause the build to fail because an attempt will be made to run AL.exe which is not available. This may be a clue or it may be another issue.

[rainersigwald]

The work-around is to either move 1.X-A.txt to the project folder or rename the file so that the name doesn't resemble a CultureInfo name.

Neither is necessary--you can instead set the metadata WithCulture="false" on the items. #5824

The docs on this could definitely be improved.

I'm also surprised X-A is being accepted as a "predefined" culture identifier--I would expect it to be rejected like @jrdodds's Y-B.

msbuild/src/Tasks/CultureInfoCache.cs

Line 70 in d074c12

CultureInfo.GetCultureInfo(name, predefinedOnly: true);

[jrdodds]

I tested the following and it works:

    <EmbeddedResource Include="Resources\1.X-A.txt" WithCulture="false" />

CultureInfo.GetCultureInfo("X-A", true).DisplayName returns "Private-Use=a". There are multiple Private-Use CultureInfo objects. "X-Z" returns "Private-Use=z" and "X-1" returns "Private-Use=1".

[baronfel]

Closing this as a duplicate of #9152. We can't really change this behavior, but we plan on creating MSBuild Analyzers that could detect non-deterministic locale names like this and direct the user to add explicit WithCulture metadata to prevent this kind of foot-gun.