Asp.net 2.0 and VSS – The Bin Directory
I’ve been working with ASP.Net 2.0 for a while now and overall I’ve been pleased with the functionality that exists in 2.0. There has been a bit of a learning curve and there are a few things that have really driven me close to the brink of insanity.
One of those things is the ASP.Net 2.0 integration with VSS. For some reason, the add to source control functionality source controls the bin directory of your site. When you have a project reference that is modified, ASP.Net will grab the new assembly and update the bin directory (as it should). The problem here is that the bin directory is now source controlled. When you build your solution ASP.Net will automatically check out the file from VSS by default. This obviously creates a massive amount of contention (because it happens for everyone working on the solution and every time the solution is built) and this has been extremely frustrating for our team. The workaround that the team has used has been to make all of the files in the bin directory read-only, but this is obviously a pretty big (and tedious) hack for the default integration behavior.
I haven’t been able to find much out there on an elegant way to work around this issue. Am I just missing something blatantly obvious here? Is this really the default behavior of VS.Net 2005 and the VSS integration? If you’ve faced this issue, what was your approach to avoid these issues?
couple of changes were made in the final release to better manage team development scenarios.
1) When add a reference to another project in the solution, the outputs form that project along with its dependencies and related files (pdbs, xml docs, etc) are copied to the bin folder of the web and are kept out of source control. The assumption is that since these are built outputs they will be updated whenever the referenced project changes. The warning dialog is probably a side effect of the fact that the server control library was originally under source control, but since these files are copied from the referenced class libraray project, they are no longer marked as under source control.
2) When you add a reference to a disk assembly, the web project system will create a file called .dll.refresh and add it to the bin folder. It will appear as a child node of the parent dll. This file contains the relative path to the source location where the reference was added from. In addition, the presense of this file keeps the referenced assembly (and its dependents and related files) from being under source control. However, the .refresh file is source controlled. This has a couple of advantages. a) When another developer opens the solution (or web site ) from source control, they will only get the .refresh files, but on first build the referenced dlls will be copied to the bin folder from the source location. and b) This allows these referenced dll’s to be auto-updated from the source location.
Here are a couple of additional points to consider:
1) Make sure the outputs from the classlibrary projects that are propagated to the Bin folder are NOT in source control. If they are in source control, you should make sure they are removed. The design is that these will be updated when the class library is rebuilt and should never be source controlled.
2) Since the web project system does not have a project file, it determines related files, like .pdb’s, dynamically and caches the list in the SUO file. If the .pdb file is not present at the time the list is cached it may appear in the pending check-ins window and appear source controlled in the solution explorer. An instance where this occurs is when you do a Clean Solution, close the solution and reopen. The pdb files may appear in the pending check-ins window and have the pending add glyph in the solution explorer. This is a trasient condition, and building the web (or the class libary) project should remove these from the pending check- in window.
Bill Hiebert
Web Platform and Tools Team