Error building when project has percent '%' char in the path

[TioLuiso]

We work with mercurial and hgflow
When a feature branch is created in hgflow, by default the branch will be named like 'feature/[FEATURENAME]'
When Jenkins wants to build that branch, creates a folder with the branch name. But it escapes the slash, resulting in something like 'feature%2F[FEATURENAME]'
Then when Jenkins launches MSBuild, the build will fail because it unescapes paths, and tries to find everything inside 'feature/[FEATURENAME]'. But that folder does not exist.

Why does MSBuild try to Unescape the path always?

[rainersigwald]

@TioLuiso What is the exact error message that you see? I just talked to @cdmihai about this and we suspect that the fix might be to escape the values we feed into $(MSBuildThisFileDirectory) and friends, but it would depend on exactly what's failing.

[cdmihai]

@rainersigwald and I looked over it and the exception is thrown here: https://github.com/Microsoft/msbuild/blob/master/src/XMakeBuildEngine/Construction/ProjectRootElement.cs#L1946

XmlTextReader seems to be lazy opening the file.

MSBuild.exe D:\projects\tests\globbing\b\%62uild.proj
Microsoft (R) Build Engine version 14.1.0.0
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 8/31/2016 4:44:38 PM.
Project "D:\projects\tests\globbing\b\%62uild.proj" on node 1 (default targets).
D:\projects\tests\globbing\b\%62uild.proj : error MSB4025: The project file could not be loaded. Could not find file 'D:\projects\tests\globbing\b\build.proj'.
Done Building Project "D:\projects\tests\globbing\b\%62uild.proj" (default targets) -- FAILED.

Build FAILED.

"D:\projects\tests\globbing\b\%62uild.proj" (default target) (1) ->
  D:\projects\tests\globbing\b\%62uild.proj : error MSB4025: The project file could not be loaded. Could not find file 'D:\projects\tests\globbing\b\build.proj'.

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.15

I guess we'll have to read the file ourselves and pass it into XmlTextReader as a string

[rainersigwald]

We also peeked into the internals of XmlTextReader and it looks like this is because it treats any call to its string constructor as a "UriString". I guess it doesn't escape it properly there.

I don't think we'll have to read + pass a string--we should be able to pass a Stream.

[TioLuiso]

@rainersigwald hmmmm. The tricky thing is that path-wise could be very well that both unescaped and escaped paths correspond to two valid and different folders. In my example above:
Unescaped : 'feature/[FEATURENAME]' is a valid folder name
Escaped: 'feature%2F[FEATURENAME]' is a valid folder name different from the one above.

So I believe the trick is not to escape or unescape the Project folder, but keep it as it is.

I ignore whether this is practic or even feasible. So I beg your pardon in case my suggestion is aberrant

[TioLuiso]

@cdmihai That's it
Also I have seen similar poblems with import:
"C:\Users\ldesantiago\Downloads\feature%2FTest\atrintegra\Ingestion\ATRIntegra.Ingestion.sln" (Clean;Rebuild destino) (1) ->
"C:\Users\xxxxx\Repos\feature%2FTest\TestSolution\TestProject\TestProject.csproj" (Clean destino) (12) ->
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.CSharp.CurrentVersion.targets(321,5): error MSB4019: No se encuentra el proyecto imp ortado "C:\Users\xxxxx\Repos\feature\Test\TestSolution\packages\Microsoft.Net.Compilers.1.3.2\tools\Microsoft.CSharp.C ore.targets". Asegúrese de que la ruta de acceso de la declaración es correcta y de que el archivo se encuentra en el disco. [C :\Users\xxxxx\Repos\feature%2FTest\TestSolution\TestProject\TestSolution\TestProject\TestProject.csproj]

Also happens with referenced dlls from packages

"C:\Users\xxxxx\Repos\feature%2FTest\SolutionFolder\Solution.sln" (destino predeterminado) (1) ->
"C:\Users\xxxxx\Repos\feature%2FTest\SolutionFolder\ProjectFolder\Project.csproj" (destino predeterminado) (54) ->
(CoreCompile destino) ->
CSC : error CS0006: No se encontró el archivo de metadatos 'C:\Users\xxxxx\Repos\feature/Test\SolutionFolder\packages\package.1.0.97.126\lib\net452\package.dll' [C:\Users\xxxxx\Repos\feature%2FTest\SolutionFolder\ProjectFolder\Project.csproj]

Have changed the paths and solutions and projects and also it is in spanish. But fundamentally you see that when tring to look for imports or packages, looks for the unescaped path, with (in this particular case) is wrong

[rainersigwald]

Escaping the path wouldn't affect the feature/[FEATURENAME] versus feature%2F[FEATURENAME] case, because escaping the first string wouldn't change it--we'd only escape URL characters. But that might cause its own problems (for example with spaces, which are legal path characters but become %20 in a URL).

I think the best thing to do here is to work around the XmlTextReader issue and see if that fixes everything (we can only hope), or if there are lingering issues.