After a short exchange of friendly but accusatory cross-continental messages, I’ve learned something new about .NET projects today. Let me start with the symptoms as that’s the first thing I Googled for and how I suspect others will find this and save themselves some pain in the future.
Let’s say you have a solution like this:
This is a brand newie right out of the box to demonstrate the problem. The web project references the ClassLibrary project as a project reference. In other words, the project file contains something like this:
<ProjectReference Include="..\ClassLibrary\ClassLibrary.csproj"> <Project>{705479f2-2820-44ea-a983-f03c70ae0754}</Project> <Name>ClassLibrary</Name> </ProjectReference>
So far, so good. However, when you go to build it gets decidedly unhappy:
I tried all the usual tricks; clean the solution, remove then add the reference, inspect diagnostic build output and of course exercised the obligatory hurling of abuse. Nothing. It wouldn’t build in Visual Studio nor would it build from the command live via msbuild. The error about the missing DLL from the referenced project remained.
However, it would build on the build server. And it would build on a colleague’s machine. And it would build on my other machine. It just wouldn’t build on the machine I wanted it to.
Eventually I checked it back out of source control into another path on the original machine and how about that – it built! That’s when suspicions arose about the path name; it had escaped spaces in it.
Now spaces aren’t my usual way of naming solution paths and in fact spaces at all are a bit of a no-no in my book because of exactly this sort of thing. What had happened was that someone else (no, really, this isn’t one of those “I have a friend with a problem” things, it genuinely was someone else) had decided to name the path this solution exists in within Subversion with a space. In an effort to provide some speedy assistance with a problem, I had simply browsed to the path in the browser (thank you VisualSVN Server), and copied the URL. The browser had quite rightly escaped the path for the URL context so spaces were converted to a %20. When I then pasted the path into TortoiseSVN to check it out, its default naming convention created the checkout directory with the same name as the repository URL and that’s where all the trouble began.
Interestingly, Visual Studio is pretty explicit about its dislike for the escape character (or more specifically, the % character) if you attempt to create a new solution containing the offending char:
It’s unfortunate it can’t also tell you that when opening an existing solution! But what it also won’t tell you is that if you create a new solution in a path which already contains an illegal character, the same build error will occur. Brand new solution, you’ve just embedded it somewhere beneath an unfriendly folder name. Rather confusing, if you ask me.
I’ve submitted this as a bug to Microsoft Connect under Visual Studio does not warn when opening a solution in a path with a disallowed character (then fails build). Let’s see if anyone picks it up.