views:

1005

answers:

5

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.

A: 

This seems to be normal for VS2008, it checks out the .sln file when opening a solution. I dont like it either.

Your problem however is the fact that the .suo file is also checked in. This file should not be placed under source control. It is like the proj.user files. I suspect suo stands for Solution User Options.

leppie
As my other comment - the .suo file is view private rather than a ClearCase element.
Alan Mullett
I see, like said, I have the same issue. But not causing any problems except the odd occasion going out of sync.
leppie
A: 

You could:

  • update your script in order to hijack the sln file in your snapshot view just after your "cleartool update -force -overwrite".
  • or, to avoid the sln to be checked-out, you could try and keep the .suo file checked-in,

If the above suggestion works, then here is a couple of reason why one would want to keep this file under version control:

  • Since the .suo file is disposable (VS2008 just creates a new one if it does not exist), having under source control might been seen as a way to avoid that creation (hence avoiding the ClearCase plugin detecting it and trying to "add to source control" it or checking it out).

  • Another advantage to having .suo file under version control (but not updated through any further checkout/checkin) is when you are comparing your checked out project with another checked out version of the same project downloaded elsewhere: that file will always be identical, as opposed to systematically different (since if is a binary file, and any new version of a binary file would register itself as different)

VonC
Thanks for your answer. I need to clarify that the .suo file isn't under ClearCase but is view private. It's the point where it recreates the missing file that it tries to checkout the .sln file.
Alan Mullett
+1  A: 

Check this also: How to integrate ClearCase with VS 2008

+4  A: 

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.

Alan Mullett
Ha, I have done similar things to addons in VS, just rip them out!
leppie
Thank you for the feedback. +1
VonC
+1  A: 

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.

Timothy Carter