1

When I tried to open a solution today, Visual Studio 2015 marked each project in the solution explorer with load failed. The "solution" output window reported the following exception, once per project:

C:\Users\Path\To\My\Project\Foo.csproj : error : The expression "[System.IO.Path]::Combine("C:\Users\My Name\Documents\Visual Studio 2010\Projects", obj\Debug\Fakes)" cannot be evaluated. Illegal characters in path. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Fakes\Microsoft.QualityTools.Testing.Fakes.targets

Trying to open a few more solutions I found out that Visual Studio now reports these errors for any project it tries to open.

I reset all Visual Studio settings, which didn't solve the issue. Microsoft Fakes seems to be a mocking framework for testing purposes (correct me if I'm wrong); the projects didn't contain any tests, nor have I accessed Fakes intentionally.

I am not aware of having changed anything related to Visual Studio or the solutions in question since yesterday, when everything still worked. My parallel installation of Visual Studio 2010 still works fine and can load the solutions and projects.

As an experiment, I edited the file mentioned in the error message, Microsoft.QualityTools.Testing.Fakes.targets, particularly the following line:

<FakesIntermediatePath>$([System.IO.Path]::Combine('$(ProjectDir)','$(IntermediateOutputPath)Fakes'))</FakesIntermediatePath>

I replaced '$(ProjectDir)' with a constant string; this makes Visual Studio load the projects again, but since I'm not sure what the purpose of this script is, I'm hesitant to use this workaround. Also this suggests that the value of $(ProjectDir) might contain invalid characters, which I couldn't confirm. I'm also wondering why the Fakes intermediate directory might be placed directly in the directory in which Visual Studio places its projects.

2

While typing up the question I found the cause of the issue.

While I didn't change any Visual Studio settings yesterday, what I did do was add an environment variable called PROJECTDIR that pointed to my Visual Studio 2010 projects directory. The script must have accessed that variable instead of its own one. After renaming the environment variable, Visual Studio is able to load the projects again.

That's the reason Fakes tried to set up its intermediary directory in my Documents\Visual Studio 2010\Projects directory, rather than in a subdirectory of the actual project. In hindsight it seems obvious, but at the time I simply didn't make the connection between a system environment variable and a variable used by a "targets" script.

I'm still posting this here because this kind of interaction is often hard to detect, and maybe this post will save someone some trouble in the future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.