EmbededFileProvider doesn't work with paths/filenames with special characters

[shutdown256]

If you have embeded resource in folder containing dash "-" in its name it gets translated into underscore inside an assembly. EmbededFileProvider is not respecting that.

I've put together quick (and probably dirty) fix:

var sc = tsp.Count(c => c == '/' || c == '\\');
var sp = 0;
for (var i = _baseNamespace.Length; i < builder.Length; i++) {
    if (builder[i] == '/' || builder[i] == '\\') {
        sp++;
         builder[i] = '.';
    } else if (builder[i] == '-' && sp < sc) {
         builder[i] = '_';
    }
}

[DamianEdwards]

@Eilon @muratg can we assign this to a dev to investigate pls?

[muratg]

@BrennanConroy Could you investigate?

[BrennanConroy]

Confirmed folders with '-' are converted to '_' in the Assembly

Would we like provider.GetFileInfo("test-name.resource"); and provider.GetFileInfo("test_name.resource"); to have the same behavior? (assuming test-name is the folder the resource is in)

[Eilon]

@BrennanConroy I recall discussing this a while ago - do we even know a way to fix this? Aren't there ultimately always going to be ambiguities in the names of embedded resources due to how the compilation system stores the paths?

[BrennanConroy]

Yes there will be an ambiguity between folder names with - and files named the same but with _

[moozzyk]

/cc @victorhurdugaci

[victorhurdugaci]

Yeah, those names have to be valid C# identifiers and that's why - gets converted to _. Of course if you have a-b and a_b as two different names, you're going to get a name collisions

[Eilon]

So can we do anything about this? What would a theoretical, regardless-of-cost fix look like?

[muratg]

It doesn't look like there's a namespace/directory hierarchy for assembly resources (though one exists for languages).

One ugly, not even fully correct mitigation could be converting - to ___ (or something similar) instead.

I remember having a similar problem in DNX time where environment variable names could not contain certain characters in Linux and OS X, and I believe we had done something like this there.

[victorhurdugaci]

The name transformation function doesn't have an inverse. Once a name is converted, you cannot convert it back.

@muratg ___ would not work because a-a and a___a would collide. It's a one way transformation, nothing you can do about it. The environment variable is different because there you don't support the other character, here you support both.

Maybe we discussed this but I don't remember, why can't the embedded file provider do the transformation before reading?