I usually nag about VSS but VSS is not always to blame when issues arise. In the old VS2003 days when someone created a new Web Project, a project (*.csproj or *.vbproj) file was automatically generated storing information about your website, its references and any used binary files. Thus when you needed to use source control for your web site project files binaries (dlls) didn’t have to be stored as well. Using the new feature of file system based web sites, all project files are now saved in a plain file system folder and there is no project file defining the web site references. The referenced assemblies are just saved in a special folder called “bin” and the compiler knows that it has to look in that folder in order to get the required assemblies and built the site.
That’s all fine when you reference assemblies that don’t change (already built dlls). In this case, you just add them to source control as well. After they will be needed if someone else downloads the site from source control in order to build it. The problem arise when you reference another library project in your web site. In this case the library assembly gets copied in your web site bin folder each time you built your solution and assuming that you’ve already added your website to source control, it will show the just copied assembly as a file that needs to be added to source control. If you go ahead and add it you’ll have to check it out each time you build your web site. If you choose to let VSS complain about it (it really gets on my nerves) and decide not to store binaries in your source control database (as you’ve probably learned at school) then the you’ll certainly be able to build without vss prompting you to check it out, but any other user that downloads your web site project from source control won’t be able to built it because of the missing assemblies.
I’m curious, how are you handling this issue?
Had same problems,
migrated to WebApplicationProject…