WPF Project BAML Resource path include Space . save project error.

[Tearies]

Steps to reproduce

1.New WPF Project Whith a Dir Name Include ' ' . eg:Resource Test
2.Add Control reference the source
3.Decompile the WPF Project out put dll.

Error message shown

resource dir name is Resource%20Test

Details

• Product in use: e.g. ILSpy
• Version in use: e.g. 9.0.0 preview 3
• Any other relevant information to the issue, or your interest in contributing a fix.

[Tearies]

replace the new assembly and run again
and raise exception can't find resource "Resource%20Test\logo.png"

[greenozon]

do you mean the issue is %20 and should be just space?

[Tearies]

Yes

[greenozon]

@siegfriedpammer I guess I've bothered you in the past with similar issues!
could you please fix the space issue pls :)

[siegfriedpammer]

Can you please provide an example binary? I have tried to reproduce this, but I am unable to recreate the exact test case in VS... VS keeps escaping/replacing my spaces :(

Thanks a lot!

[Tearies]

Source

Error

[Tearies]

SpaceBamlDecompile.zip

Assembly

[greenozon]

dnSpyEx shows as follows:

[siegfriedpammer]

Seems URI encoding/decoding is specific to ".resources" files... I will add this to the project export only... So upon invoking "Save Code", "a%20b" is turned into "a b", which our filename sanitizer will turn into "a-b"... I hope that this is an acceptable solution. Thanks!

[Tearies]

Xaml compiles to encode spaces. If the Uri reference is not synchronized, it is better to restore it to spaces.

[Tearies]

dnSpyEx shows as follows:

It should be like this

[siegfriedpammer]

We escape spaces in filenames/paths because they usually only cause trouble and if you are going to try to recompile something after exporting it as a project, I think fixing up the names of resources is the least of your problems - especially if the assemblies are obfuscated.

[Tearies]

It is because I need to export it and compile it again. The path of the resource file will be encoded again. The "%20" character will be re-encoded as the original character. Then the place where I reference this resource will not find the corresponding resource, resulting in a program error. So I will pay more attention to this problem. Of course, if I just want to take a look at the implementation logic, then I don't need to care too much about this problem.

[Tearies]

The problem of assembly obfuscation is indeed something I have not considered. But if the obfuscated place uses this resource, it will also use the obfuscated one. If we recompile, there will still be problems in use. Just like dnSpy. They should have considered this situation. Otherwise, they will also have %20. dotPeek outputs _25020, and I will do a lot of resource searches and modifications.