views:

877

answers:

3

(I know I am using Visual Source Safe, I do not have a choice because it comes with the MSDN Subscription license and my company does not want to buy a third party source control solution....)

I have a VS 2005 solution with 3 C# class library projects, 2 ASP.NET web site projects and one ASP.NET web service project that is stored in a Visual Source Safe database. Some of the projects reference a common library DLLs that handle common taskes.

When a new person sets ups the solution on their workstation and build it for the first time, it checks out the common library DLLs in the bin folder of the ASP.NET web site and web service projects. When another developer that is currently working on the project tries to build, they receive a "file excludely checked out by other user" message.

VS 2005 does not display the check mark next to the DLL that is causing the headache.

Is there a way to prevent this from happenning?

+1  A: 

Not sure if this is the problem or the best fix, but if you update every developer's machine so that they have the same latest versions of the common DLLs installed, this shouldn't keep happening. I think VSS checks out the DLLs in the \bin folder if the version referenced by the project file doesn't match the version installed on the developer's machine.

MusiGenesis
I just checked and the "Date Modified" for each common library DLLs in the \bin folder for each project and they are different from version installed on each developers work station.
Michael Kniskern
That might not be it. I think the Date Modified just shows when they were copied locally from VSS, so that would always be different. Are these DLLs your own projects, or third-party DLLs? Are they ActiveReports or Log4Net by any chance?
MusiGenesis
The our our own DLLs but they are seperate project outside of this solution, so I guess they would be considered third party DLLs. No they are not ActiveReports or Log4Net.
Michael Kniskern
Another thing to do is to rigorously enforce the policy that everyone checks things out to the exact same location on each machine. If different developers have different absolute paths to the same file in VSS, this problem can occur.
MusiGenesis
In other words, if one dev has everything in "c:\Projects\OurApplication" and another dev checks stuff out to "c:\Program Files\Visual Studio 2005\Projects\OurApplication", VSS won't like it.
MusiGenesis
we currently enforce that policy
Michael Kniskern
Sorry, I'm down to "stop using VSS". We had this kind of problem perpetually until we switched to something else. There may be a way in VSS to mark a \bin folder as something it should ignore, but that's all I got, sorry.
MusiGenesis
Trust me, I want to stop using VSS too. I will have to run it by the team to which direction they want to move forward with source control. Thanks for your help....I gave you a plus +1.
Michael Kniskern
+2  A: 

Why do you have the bin folder checked into SourceSafe? On projects I've worked on, the third party dlls were checked into a separate folder (maybe called ExternalLibraries or ThirdParty) at the same level as the solution file. The compile process would be set up to copy the dlls into the bin folder. This could be handled with .refresh files, or with a pre- or post-build step. This way, VisualStudio/SourceSafe won't see the files as having been updated, and won't try to check them out.

If the compile is already pulling the files in due to them being dependencies, I'd suggest removing the bin folder from VSS. This is not the same as an "Exclude folder from project" which hides the folder from VS05 when compiling (and gives you the compile error you mentioned.)

If the third party dlls aren't going to change, another option is to make those files read-only in VSS. This way, no users will be able to check out the files. (To mark the files read-only, you will need to change the permissions from the VSS management tool; the developer's tool doesn't have that feature.)

As for why it happens, I don't believe VSS checks the binary version numbers - it is only concerned with modify file date. If a new developer pulls all the code out, all files (including binaries) will have the current date as the modify date. This may be causing the unnecessary checkouts.

Regarding your later comments - I'm not sure why VS05 wouldn't see the files as under source control but the VSS UI does. I suspect it has to do with the .vss files (and similar) that are in that folder. In this case, VS05 is incorrect.

Pedro
A: 

@Pedro:

In the VS 2005 IDE inteface, it does not indicated that the \bin folder is in VSS. When I look at the project in the VSS UI, it shows that is checked out to the user who did the latest build on their workstation.

If I use the "Exclude folder from project" option, it will cause the compiler to throw "reference not found" errors.

In my solution structure, the class library project creates a reference to the third party DLLs using the "Add Reference" command. Then I set a project reference to the class librarys in my ASP,NET web site and web service projects (using the web site project template). Because the class library has a dependency on the third party DLLs, they are copyed in the \bin folder.

How do I set a file to read-only through the VSS UI?

Michael Kniskern
I updated my original post with additional info. If the files are being copied to the bin folder correctly each time, I'd recommend removing the bin folder from VSS. This should address the issue.
Pedro