dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.21k stars 1.35k forks source link

Resource Names Case Insensitive - Why? #5658

Open PtkFerraro opened 4 years ago

PtkFerraro commented 4 years ago

I am working in a project that need to have localization.

When compiles, I get a warn that I have duplicate resourne names.

Lookng the resource, they are not duplicate, the problem is that it uses case-insensitive, causing resources name like 'total' be the same of 'TOTAL' or 'Total'.

  <data name="Total">
    <value>Total</value>
  </data>
  <data name="TOTAL">
    <value>TOTAL</value>
  </data>

Is this correct to behave like this ? How can I do an work around? I have a list of more than 200 duplicates and will me impossible to do by hand this... would be possible to do a bypass on this check?

I am using .Net Core 2.2 on my Mac OSx and I have an API project that gets the SharedResource from another project (Class library)

Here is the call:

https://github.com/dotnet/msbuild/blob/df645299a158c787f9884fca2bcd8c295318193f/src/Tasks/GenerateResource.cs#L2090

Here is where I think the problem is:

https://github.com/dotnet/msbuild/blob/df645299a158c787f9884fca2bcd8c295318193f/src/Tasks/GenerateResource.cs#L1467

benvillalobos commented 4 years ago

Thanks for filing the issue. The change seems like a relatively easy fix, my concern is how this affects customers who have grown to expect this behavior. Consider that it's been this way for 8 years.

Should we choose to create a workaround: The only way I see working around this is checking if an environment variable is set. Such as MSBUILDCASESENSITIVERESOURCES. When set we can change the string comparer to StringComparer.Ordinal

Forgind commented 4 years ago

Many parts of MSBuild are case-insensitive, and changing them all to be sometimes case sensitive would cause a lot of confusion up front. Having a mix of case-sensitive and case-insensitive parts is probably even worse over the long term.

The easiest workaround I can think of is to write a script that modifies the names to be more substantially different—perhaps adding a random string, a hash, or a set of flags (0000 for all lower-case vs. 0110 for the middle two letters upper-case, for example) to each resource name. Would that work for you?

PtkFerraro commented 4 years ago

@Forgind That´s what I did. I have a script that grabs all localizer words and generates a spreadsheet. I made a change to add a hash in the end.

I am wondering why in C# (Case Sensitive) on machines Linux/Mac (Case Sensiteve), the MSBUILd uses Insensitive for some parts...

cheers

Forgind commented 4 years ago

I don't have a great answer for you; perhaps someone has a better idea. The biggest issue in my mind is that a build should succeed or fail in exactly the same way on any OS. It's relatively easy to find examples in which, if we always took into account your OS's casing preferences, that wouldn't be true, and it could cause very confusing errors.

A second aspect is that there are certain parts of MSBuild (like properties) that are always case-insensitive. That design decision was likely made with Windows in mind. Having some parts of MSBuild always case-insensitive and other parts depend on your OS is confusing, but trying to make everything depend on your OS would be a major breaking change at this point. I wish I could give you a better answer.