IVF 9.1, VS 2005, and VSS

[a_leonard]

We have a solution with 38 projects which was converted from CVF that is shared by several developers. The project and solution files are all in SourceSafe. Whenever we try to build, a dialog pops up for each project that says the files must be checked out or writable. You can proceed without checking out the files, but you have to hit "OK" once for each project to keep the build going, which ties you to your desk for at least 10-15 minutes every time you make a change to the code.

If we check out the files and save all the projects when we close Visual Studio, they look completely different at first glance. The differences seem to be in a reordering of the lines and not in the real content, however. Regardless, the merge feature of SourceSafe is pretty much useless because of the shear number of lines changed.

I also haven't figured out how to get the files checked out automatically, although we had bad experiences integrating SourceSafe and Developer Studio when we were working with CVF.

If we leave the files read-only, then it seems like the entire project is out-of-date and everything is rebuilt, which is not acceptable.

I haven't been able to reproduce this when I try to set up a solution from scratch (and can't send a simple example to support), so I suspect there is some setting that is causing our grief.

Has anyone run into similar troubles and have a suggestion?

[Jugoslav_Dujic]

There was a similar problem presented here recently (I don't feel like digging it up though). The culprit was that the user has also put a temporary project file (containing source safe checkout information, project changes etc.) to source control, which caused the information to be either wrongly shared or not be written there (because of read-only status). I think it's the .suo file, but don't take my word for it.

[a_leonard]

I don't think this is caused by having any temporary files checked into SourceSafe. The only files are the source files, the project files (*.vfproj and *.vcproj), and the solution file (*.sln).

I am trying to find the differences between what is in SourceSafe and what I have after checking out the project files and building. For example, here is one piece of one project file. (Sorry about the formatting, the long lines are wrapping and I don't know how to control it.)

My copy:

&n bsp;

SourceSafe:










< ;Tool Name="VFLibrarianTool" OutputFile="$(OutDir)/$(ProjectName).lib" SuppressStartupBanner="true"/>


When compared in SourceSafe using the visual format, they look very different, but mostly the "Tool" elements are reordered. The only real difference between the two is that the element with the attribute Name="VFLibrarianTool" also has the attribute MustRebuild="true".

Is there a way to get Visual Studio to write the project files in the same order so this comparison is easier to make?

Do the attributes "MustRebuild" and "SwitchesHaveChanged" have anything to do with the need to have the project files writable?

[Jugoslav_Dujic]

I know the format of .vfproj files only superficially, but yes, SwitchesHaveChanged and MustRebuild affect whether the projects should be rebuilt. Try to edit those manually to false and check them in to VSS as such. As I get it, the idea is that VS would automatically check in/out projects as necessary, but the mechanism probably has glitches.

(To insert the code or raw text output in the Forum, use "Formatted" style from "Paragraph" combo).

[Sachin_m_]

I see the same issue with Visual Studio 2005, IVF 9.1.037 and Perforce. As of now I've not found a solution for this :(

As a workaround I could ask each developer to checkout (and leave open for edit) all the .vfproj files. But it is a messy workaround as Perforce would not update these files left open for edit when they are actually updated in the repository.

The "MustRebuild" flag is also written out by VS2005+IVF interface so I don't see any point in manually deleting it. VS2005 puts it back in randomly when vfproj is edit the next time.

If there is any way to control this, that would be great.

-Sachin