setup:
- all development being done on virtual servers (Win Server 2003)
- all compiles being done in VS 2010
- all code checked into TFS 2010
We are migrating our solutions from VS 2008 to VS 2010. I created a MAIN branch folder for containing our converted VS 2010 projects. I then branched over and worked through getting projects migrated from 2008. The compiles were (eventually) successful. Another developer was working through other projects on the same branch.
We then got all of these projects compiling also through TFS Build 2010.
This is our MAIN branch. Another developer then created a DEV branch folder and branched all of the solutions from the MAIN branch to the DEV branch for ongoing development.
Much to our surprise, we found that though we could compile the code if we did a get latest on the MAIN branch, when we did a get latest on the DEV branch (supposedly the same code), some of us (we’ll call them the unlucky developers) got a slew of errors having to do with a reference to a project contained in the solution. But two developers (lucky) had it compile just fine. When the two unlucky ones compile the individual project (the one causing the reference error) it builds fine, but when we build the solution or the referencing project, it fails with the reference to that project.
We tried wiping out our workspace and doing a get on the code fresh – no joy.
The lucky person who created the branch did the same (deleted their workspace, did get latest and ran a compile) and it still compiles. We then had a developer that hadn’t been involved in the migration do a get latest and run a compile. Their compile ran just fine too! This led us to believe that it must be the computer.
So then we had one of the unlucky developers log into one of the lucky developer’s virtuals and perform a get latest and build using their own workspace. This also failed. So this virtual has one workspace under one user that succeeds, and one under another user that fails to compile for the same get latest on the same code.
Then… we detached the working workspace from the lucky developer’s virtual and one of the unlucky devs attached to it (no get, just compile what’s there). That compiled fine.
So it feels like we may have some sort of characteristic attached to us unlucky devs that are causing our Gets to be different. One difference I just realized is that we two unlucky ones have shelvesets that we saved in TFS in the 2008 versions (but under TFS 2010).
OK, Then… the same unlucky developer wiped out the lucky one’s workspace by deleting the files and then performed a get specific / latest / both force overwrite switches turned on. This compiled successfully!!
Then he went back to his original virtual machine. He deleted the files in his workspace, and did a get specific / latest / both force overwrite switches turned on. This compile again failed!
We’re running out of ideas…
Well we got bit once again. The issue had to do with the length of the path to the source code. Of course there is no indication of this in the actual error. This is probably the 8th time I have run into this. It is frustrating while trying to keep namespaces meaningful to constantly have to trim these paths.
We had dismissed this possibility, because the names of the developers who were able to compile the code were longer than the two who couldn’t, and the names are in the path of the workspace by design so that multiple developers can work on the same virtual machine as needed.
I believe I found out why. I had my compile set to “Mixed Platforms” and the ones who could compile were set to “Any CPU” Maybe this was in the path.
The solution was (once again – this is getting really old) to move the project down a few folders instead of containing it where we had hoped to. This reduced the number of characters in the path and the compile ran just fine. Ugh.