MSBuild doesn't parse environment variables in .sln files

[playmer]

This is a replication of a bug on Microsoft connect.

"Currently we are using environment variables to specify where to find projects within our VS solution files. Visual Studio seems to handle this fine but when trying to build the solution via MSBuild, we get an error due to it not parsing the environment variable at all."

This was marked "Won't Fix" in 2011. Is there anything keeping someone from fixing this, or was it just determined not suitable for the next milestone?

[playmer]

Hey, so I started looking into this, and I think it's a relatively easy fix, but right now I'm running into (seemingly unreleated) issues with running the provided tests as well as running on my project.

With a pulled version of the repo (at the tip of master with no changes), I'm seeing the following five tests failing:
SolutionGeneratorCanEmitSolutions
SolutionGeneratorEscapingProjectFilePaths
TestDefaultWhenNoSubToolset
TestGenerateSubToolsetVersionWhenNoSubToolset
VerifyDefaultSubToolsetPropertiesAreEvaluated

and I'm running Visual Studio 2015 RC. Is there some more environment stuff to set up beyond just installing 2015?

As for testing my change for my project the only change I made in my dirty branch is changing line 1244 (src/XMakeBuildEngine/Construction/Solution/SolutionFile.cs) from:
proj.RelativePath = match.Groups["RELATIVEPATH"].Value.Trim();

to:
proj.RelativePath = Environment.ExpandEnvironmentVariables(match.Groups["RELATIVEPATH"].Value.Trim());

And as I step through it appears to expand the variables, but it can't seem to run my solution:

C:\Sandbox\Zero\Zilch\Project\StandardLibraries\Math\Math.vcxproj(22,3): error
MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. C
onfirm that the path in the declaration is correct, and that the file
exists on disk.

I can email the solution for testing if need be.

[playmer]

Seems that that last bit was an environment issue, I do seem to be running into other similar issues, but I suspect they'll boil down to the same thing.

[akoeplinger]

@playmer FYI, the C++ targets aren't included in this repository, only C# and VB so it won't work for building vcxproj's.

[playmer]

@akoeplinger Well that would be a problem. I'll spend some time testing with a C# project then, thanks for letting me know!

Is there any way we could get the C++ targets on GitHub or is there something preventing it?

[akoeplinger]

According to #106 they aren't open sourced at this point. I don't know if it's planned to change this in the future :)

[plato-cambrian]

I think that this is relevant to this stackoverflow issue which i encountered while attempting to build eventstore

[cowlinator]

This python script is a janky workaround for the .sln parsing.

# Python 2.7
# usage: python fix_sln.py path/to/file.sln
import codecs
import os
import re
import shutil
import sys

if __name__ == "__main__":
    with codecs.open(sys.argv[1], encoding='utf-8-sig') as orig:
        with codecs.open(sys.argv[1] + '.modified', 'w', encoding='utf-8-sig') as new:
            for line in orig:
                line = line.rstrip('\r\n')
                found = re.search(r"""%.+%""", line)
                line = line.replace(str(found.group()), os.environ.get(str(found.group()).replace("""%""", ""))) if found else line
                new.write(line + '\r\n')
    shutil.move(sys.argv[1] + '.modified', sys.argv[1])

It simply replaces environment variable names with their values in the .sln file. Msbuild can then parse the .sln correctly.

[sicklittlemonkey]

The originally provided link is dead:

This is a replication of a bug on Microsoft connect.

But this one with a suspiciously identical name from 2018 says it was:

Fixed In: Visual Studio 2019 version 16.0

Was it actually fixed for msbuild? It doesn't seem to work for me.

[rainersigwald]

This is either fixed or a feature request for https://github.com/microsoft/vs-solutionpersistence now.