Comments on: Asp.net 2.0 and VSS - The Bin Directory http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/ Thoughts by Ben Carey Tue, 06 Jan 2009 10:33:54 +0000 http://wordpress.org/?v=2.6 By: Gabriel Lozano-Morán http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-31 Gabriel Lozano-Morán Mon, 07 Aug 2006 09:34:43 +0000 http://www.thesherpaproject.com/?p=32#comment-31 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++. 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++.

]]> By: Ben Carey http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-27 Ben Carey Tue, 01 Aug 2006 19:59:13 +0000 http://www.thesherpaproject.com/?p=32#comment-27 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 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 :)

]]> By: Dave Robinder http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-30 Dave Robinder Tue, 01 Aug 2006 18:25:04 +0000 http://www.thesherpaproject.com/?p=32#comment-30 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 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.

]]> By: Ben Carey http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-29 Ben Carey Thu, 20 Jul 2006 01:58:09 +0000 http://www.thesherpaproject.com/?p=32#comment-29 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 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.

]]> By: bhupinder http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-28 bhupinder Wed, 19 Jul 2006 14:00:29 +0000 http://www.thesherpaproject.com/?p=32#comment-28 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? 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?

]]> By: Ken http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-26 Ken Wed, 08 Mar 2006 03:49:54 +0000 http://www.thesherpaproject.com/?p=32#comment-26 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 :-P 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 :-P

]]> By: Norman Seymore http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-25 Norman Seymore Wed, 08 Mar 2006 03:49:09 +0000 http://www.thesherpaproject.com/?p=32#comment-25 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. 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.

]]> By: Ben Carey http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-24 Ben Carey Wed, 08 Mar 2006 03:48:45 +0000 http://www.thesherpaproject.com/?p=32#comment-24 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. 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.

]]> By: GS http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-23 GS Wed, 08 Mar 2006 03:48:21 +0000 http://www.thesherpaproject.com/?p=32#comment-23 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? 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?

]]> By: Ben Carey http://thesherpaproject.com/2005/11/30/aspnet-20-and-vss-the-bin-directory/#comment-22 Ben Carey Wed, 08 Mar 2006 03:47:51 +0000 http://www.thesherpaproject.com/?p=32#comment-22 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! 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!

]]>