VS2008 and ClearCase : opening solution requests a checkout for no reason

Question

I have a little issue that's causing my automated builds to fall over.

When we open a solution recently converted from VS2005 to VS2008 VS through ClearCase requests that we checkout the solution file.

If we allow it then it makes no changes anyway and by default ClearCase doesn't like checkins without changes. So we undo the checkout - and from then on VS is happy, it was able to write the .suo file.

If we un-read protect the solution file, start up VS2008 it creates the .suo file ok, if we then un-hijack the .sln file (no changes anyway so VS2008 doesn't notice) and fire up VS2008 again it's fine - doesn't ask for a checkout.

In my build script I delete all view private files from the view and then do an update with forced un-hijack of controlled files. And then we build the deployment projects (and thus all dependencies), and as the .suo file is being deleted it falls into the checkout .sln file behaviour every time.

And on the build server there isn't anybody around to see the dialog asking for a checkout, the build hangs.

I could change (aka bodge) the build script to not delete the .suo file, but I would rather not do this.

edit: clarification - the .suo file is NOT checked into ClearClase - it is a view private file that is being created by VS2008, however to create this file it wants to check out the .sln file for not real reason.

Further Edit:

I have found the solution to this - I've disabled the integration as per my follow up post on this thread.

Answer 1

Okay, I found the solution to the problem and it was quite simple in reality.

I disabled the Visual Studio ClearCase integration on the build server.

VS is being used as we need to build deployment projects and so we call devenv to do this for us. However we are only using it as a build engine, there is never a need for the build engine to know how to modify the source items as they will all have just come from ClearCase. The only items we allow the build server to modify are the assembly file version number attributes in the AssemblyInfo files, but we do that in the NAnt and not in Visual Studio.

So, disable the functionality and problem goes away. Probably not the solution for everybody but on a build server it was the way forward.

Answer 2

This troubleshooting item, got me to this fix pack which has solved the issue in our development environment. We're still using VS2005, but I would expect that it's the same issue as what was going wrong in VS2008.