Subversion and ASP.NET Website Project's Bin folder

Question

We're in the middle of changing from VSS to Subversion and we have a website project on our Subversion Repo. We've removed the Bin folder as it causes all kinds of chaotic tree conflicts since our development solution contains some Class Library projects the Website project depends on (set up as project references in our solution). We also have a couple of 3rd party library DLLs in the Website's Bin folder too.

The next phase of our project involves a designer modifying themes to our website. I'd like for him to be able to just open the Website project in VS 2005, modify the CSS files he needs to on his working copy, and test his files on his localhost. He'll need the most up-to-date DLL files for him to be able to do this.

Is there anyway to add the Bin folder DLLs to subversion, and configure TortoiseSVN or subversion so that we can commit our newest DLLs (project dependencies in developer's solution files) but ignore them on update (per client I guess)? It would also be handy to have our 3rd party website dependencies on Subversion too.

Answer 1

The approach we've taken is, rather than having the Libraries in the same solution, they have separate solutions and we (well, our Build server) compiles them and checks the compiled DLLs into sourcecontrol under "Dependencies" which is always mapped to C:\Dependencies on all developers machines. We then use file references to this folder from the website project.

Thi way you can give your designer the Website project along with a copy of C:\Dependencies and they'll be none-the-wiser =)

Answer 2

Would it not be possible to structure it like this:

Trunk/
  WebApp/ 
  ClassLibrary1/
  ClassLibrary2/
  ClassLibrary3/
  3rdPartyDlls/
  build.bat

The web app is what pulls all the class libraries and the 3rd party dlls in to the WebApp's Bin folder (All of these will be referenced via relative links). You can then setup TortoiseSvn to call the build.bat file on update through client side hooks. You would also setup IIS on the designer's machine to point to the WebApp directory.

As other users have pointed out, you could use svn externals to pull in those enterprise wide class libraries.

Answer 3

You should not put 3rd-party assemblies into the bin folder. In fact, you should assume that the bin folder will be emptied before each build. It is a place to put the output from a build, not a place to put inputs.

Put these binaries in to some other folder, maybe "3rdPartyAssemblies". Use a file reference to these files, and they'll be copied into the bin folder, as outputs.

Answer 4

We don't sourcecontrol the bin-folder since it would be updated everytime you run a compile. Instead, we keep references to 3rd part libs in a separete folder that is under version control, that we have references to in our project.

With this setup and using "copy local = true", they are automatically added into bin upon compilation.

Secondly, we will only commit new binary files when we update the 3rd-part binaries.

This approach is also possible to do for your internal dlls, so that your designer can just compile his visual-studio-solution so taht any relevant dlls would be put into his bin-folder and hence, create a functional site locally on his machine.

Answer 5

What most everybody else has said regarding '3rdParty' is correct.

You may also consider svn:externals to pull in related directories including a '3rdParty' assemblies directory, or even output directories from builds that can be triggered by a check in to assure currency.