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?
11 Comments
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
Thank you for the comments Bill! This is working for our team now.
The problem stemmed from us starting initially with a beta and then upgrading to the RTM. The add to source control was done from the beta.
Thanks for the help and for confirming the process for helping us rectify the issue!
How does this work with multiple configurations, for example Debug and Release? The path in the .dll.refresh can only point to one file, either the release build output dll or the debug build output dll. What happens when the other configuration is built?
There are a couple of different options available, and I think that the correct answer depends primarily on your situation. Regardless, I’ll take a shot at the answer.
The reference (and the .refresh file pointing to it) are only needed for file references. If you control the assemblies that you are referencing through the file reference then I would recommend adding the reference as a project reference and letting the reference be handled for you through the functionality provided in Visual Studio.
If you don’t control the reference then you have the option to reference the appropriate build of the assembly that you are pointing at. If you need to reference different builds at different times (e.g. you want the debug build when your configuration is debug) then I would look into using some type of build automation to copy the appropriate assembly to a common folder based on your build configuration. In this scenario, you would be pointing to the appropriate version at the appropriate time because the build configuration would determine which assembly (and the corresponding build) existed in the location that the .refresh file points to.
I’m using VSS with .net 2005. When I create a brand new solution, get it all set up to compile, and check it in, it sticks the .pdb and .xml files from project reference dependencies in the Bin folder of the web site into source control. This conflicts with the statement
“A 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.”
I can find no way to ‘exclude’ the files from source control. They shouldn’t be in there to begin with. Yes, if i remove them from source control then rebuild the site they do not show as being attached to source control, but as soon as i close the solution and reopen it they have the little ‘this is a new file for source control’ icon. That isn’t a big deal. What is, is that if i go to check the solution back into source control it insists on, by default, adding the silly things back.
I didn’t work with production projects with the beta, so I can’t say whether it has improved or not. As it stands I need to either fix my lack of understanding, or they need to fix the interface… there’s definitely a deficit somewhere.
Not sure why, but I’ve got a case where all the referenced DLL files are being dumped into the web project’s root directory instead of into the bin directory. Can’t figure out how VS.Net is determining where to put the DLLs (no config info in the .sln file). This is another case where VS.Net is trying to be too smart and hides too much stuff from users
Hi,
I have the dll.refresh file in bin directory in vs.2005 but the refresh is not working properly. It is not updating the changes made in class library. Could you help me with this?
I would check the path in the .refresh file (the file should have the path the assembly that it is referencing) and make sure that it is pointing to the correct assembly and location that you are expecting. If the path is correct, make sure that you are rebuilding the solution and that the output of your class library is building the new file to the location that matches the path in the .refresh file. If all of that looks ok, i would manually wipe out the asp.net cache files, rebuild everything, and see if you have any luck.
I think I have a handle now on the refresh file. However, I still have a problem. The developers on our team do not necessarily have a referenced DLL in the same relative location to their website location.
I have two developers working on the same site. The site references a file called DLLA.dll. On the first developer’s system, he installed DLLA.dll to his C:\Program Files directory. The second developer installed the file in his My Documents folder. The relative paths are not the same and they’re going to fight over the contents of the .refresh file. Any thoughts on this other than to make them come to terms with the directory structures/locations? You should see how this can really become a problem with 5 or more developers.
I would have them agree on a common location. I’m a big fan of xcopy, so I would put the assembly in a relative directory under my source control structure to make sure that everyone has the assembly in the same place and that all of the paths point to the same file.
Good luck
I was having the exact same problem of pdb files being source controlled. I had Visual Studio 2005 Team Edition Team Suite installed (Full Installation). After removing the Visual C++ component the problem was solved. For me this is a good workaround since I don’t use Visual C++.