Why would VS2005 keep checking out a project for editing without any changes being made?

Question

I have a VS2005 solution which contains a variety of projects (C++ DLLs, C++ static libraries, C# assemblies, C++ windows executables) that are combined in various ways to produce several executables. For some reason, every time I open the solution, VS2005 wants to check out one of the projects for editing. The project is not modified in any way, it's just checked out. If I configure VS2005 to prompt before checking out, I can cancel the auto-checkout during load with no ill effect that I can see. It may or may not be relevant, but the project it keeps checking out is cppunit version 1.12.0 (the static lib version). How can I stop this annoying behavior?

Other potentially relevant (or not) details:

• Source control is Team Foundation Server (not Visual SourceSafe)
• no .suo or .ncb files are checked in
• the .vcproj and .vspscc files are being checked out
• When I close the solution or shut down Visual Studio, I'm asked whether I want to save changes to the project. Answering yes results in no changes to the file (Kdiff3 compares my local file to the server version and reports"files are binary equal")
• Attempting to check in the "modified" files results in a Visual Studio message saying "No Changes to Check In. All of the changes were either unmodified files or locks. The changes have been undone by the server"

Answer 1

Have you put a .suo or .ncb file into source control perhaps?

Answer 2

Have you tried closing VS2005 after it checks out cppunit and then seeing if any changes were made?

I often encountered something like this with Web App solutions where the project file wasn't actually saved until you closed studio down and reopened it.

Answer 3

Just to clarify, I'm assuming that you mean Visual SourceSafe2005 is causing the problem, not Visual Studio. (FYI, Visual SourceSafe is usually abbreviated VSS.)

I've experienced this issue with VSS before. I think the limitation is really fundamental to Visual SourceSafe: it's just not that good of a product and I would move to something else if it's a decision you can influence.

If you can move to something else, I recommend Subversion for a small or medium-sized project. It's free, and does not use the pessimistic locking mechanism that Visual SourceSafe uses by default. There's an excellent Visual Studio add-on called VisualSVN that will give you the same functionality in the IDE (seeing what files have changed, etc.) that you get out of the box with VSS.

If you cannot change source control systems, I believe Visual SourceSafe has a mode called "non-exclusive checkouts" or something like that that uses the optimistic locking that Subversion and other source control systems use. Try setting that option at least for the files that are obviously not being changed and see if that resolves the issue.

Answer 4

I get this a lot when one of the projects in the the solution has source control information with path information that is not the same in source control as on your workstation. When VS opens the project it will automatically attempt to check out the project in question and

To fix it, you're best off having everyone who uses the project remove their local copies and do "get latest version..." to grab what is in your source control database.

you can also check the .sln file and look in the GlobalScxtion(SourceCodeControl) area for each project's information and see if the relative path is not how you have the projects stored on your workstation - though manually changing this file vs. doing a "Get Latest Version..." is much more likely to cause problems for the other developers who use the solution as well.

Answer 5

Your cppunit project is probably automatically creating one or more additional files when the project first loads, and then adding those files to the project. Or else one of the project's properties is being changed or incremented on load.

If you go ahead and check the project in, does it check itself out again next time you load it? Or does checking it in fix the problem for awhile?

Answer 6

Very often this sort of behavior is caused by VS trying to update source control bindings.

Graeme is correct, VS will not save project or solution files until you close VS.

I would let VS check the files out, then close VS, then diff them.

Answer 7

As Charles and Graeme have hinted at, Visual Studio constantly make changes to user option files and such on the backed even if you don't make changes to the project directly.

I'm not sure what information is being stored but I do know that it happens. Common remedies is to not include the *.suo files. I also don't stored anything in the bin or obj folders in sauce control as this can have a similar effect as your talking about (if you build). (Checks out the project upon a build. Thought this does take an action to happen).

Overall it is unavoidable. It is just how VS2005, 2008 work.

Does this answer your question?

Regards, Frank

Answer 8

There are two reasons I've encountered that cause this behavior.

The first is old source control bindings. If you have a project that used to be managed by another source control tool, it might have leftover bindings in the project file. Open the project file, and change the following settings from something like this:

• SccProjectName="$/Team/Platform/Projects/MyProject"
• SccAuxPath="http://teamFoundationServer.example.com:8080"
• SccLocalPath="."
• SccProvider="{88888888-4444-4444-4444-BBBBBBBBBBBB}"

to this:

• SccProjectName="SAK"
• SccAuxPath="SAK"
• SccLocalPath="SAK"
• SccProvider="SAK"

Different project types are defined in different ways. The above example is from a .vcproj, C# projects are in XML, VB looks like something else, but the meanings are the same. Simply set all four values to the constant string "SAK" and Visual Studio will automatically handle source control. See Alin Constantin's blog for details.

I haven't yet discovered the root of the other reason, but the project that is giving me trouble is also CppUnit 1.12.0! I'll keep digging and post my findings.

John