Preventing third-party DLLs from registering in VSS
(I know I am using Visual Source Safe, I have no choice because it comes with an MSDN subscription license and my company doesn't want to buy a third party source code management solution ....)
I have a VS 2005 solution with three C # class library projects, two ASP.NET website projects and one ASP.NET web service project that is stored in a Visual Source Safe database. Some of the projects reference shared DLLs that handle common tasks.
When a new person installs the solution on their workstation and builds it for the first time, they check the shared DLLs in the bin folder of the ASP.NET website and web service projects. When another developer who is currently working on the project tries to create, he receives a "file excluded from another user" message.
In VS 2005, there is no check mark next to the DLL which is causing a headache.
Is there a way to prevent this?
source to share
Why do you have bin folder installed in SourceSafe? In projects I've worked on, the third party dll has been checked out in a separate folder (probably called ExternalLibraries or ThirdParty) at the same level as the solution file. The compilation process will be configured to copy the DLL to the bin folder. This can be handled with .refresh files or with a pre or post build step. Thus, VisualStudio / SourceSafe will not see the files as updated and will not try to check them.
If compilation is already pulling the files due to their dependencies, then I would suggest removing the bin folder from VSS. This is not the same as "Exclude folder from project", which hides the folder from VS05 when compiling (and gives you compile error information).
If the third party DLLs will not change, another option is to make these files read-only in VSS. Thus, no user can check the files. (To mark files as read-only, you will need to change permissions from the VSS management tool; the developer tool does not have this functionality.)
As for why this is happening, I don't believe VSS checks for binary version numbers - it only deals with the file modified date. If a new developer pulls out all the code, all files (including binaries) will have the current date as modified date. This can cause unnecessary checks.
Regarding your later comments - I'm not sure why VS05 won't see files as being under source control, but VSS UI. I suspect it has something to do with the .vss (and similar) files that are in that folder. In this case, VS05 is incorrect.
source to share
Not sure if this is the problem or the best fix, but if you update every dev machine to have the same latest versions of regular DLLs this shouldn't continue. I think VSS checks the DLLs in the \ bin folder if the version referenced by the project file does not match the version installed on the developer machine.
source to share
@Pedro:
In the VS 2005 IDE, it does not indicate that the \ bin folder is in VSS. When I look at the project in the VSS UI, it shows what is issued to the user who made the last build on their workstation.
If I use the "Exclude folder from project" option, it forces the compiler to reset the "links not found" errors.
In my solution structure, the class library project creates a link to third party DLLs using the Add Link command. Then I set up a project reference for the class libraries in my ASP and NET website and web service projects (using the website project template). Since the class library has a dependency on third party DLLs, they are copied to the \ bin folder.
How do I configure a file to be read only through the VSS interface?
source to share