Use subversion for asp.net deployment - Causes appdomain recycle

Question

I am experimenting with using subversion to deploy updates to my ASP.Net application, one issue that I am facing is that whenever the working copy(containing the build) is updated the ".svn" folder inside of bin gets updated and this causes the ASP.Net appdomain to recycle. I don't want this to happen unless something in bin has actually changed.

Is there a way to tell ASP.Net to ignore the ".svn" folder inside of bin? Basically not watch that folder for changes?

If this does not work out, I'll be using a staging folder outside the web folders to download the builds onto the servers and then use scripts to patch/update the actual web folders.

[Edit:] The svn export option will not keep my deployment under version control, I want to be able to do "svn update" on the web folders to deploy and rollback releases.

Answer 1

If you use svn export instead of svn checkout to get the files from your repository you will not get the .svn folder on your server.

[Edit] Another option would be to delete "bin" from your repository (and possibly commit it to another one, if you need revisions), and then just copy the bin-catalog to your webroot manually when it changes. Remember to add "bin" to your svn-ignore-list.

Answer 2

Well unfortunately if you do this, then you will, as you're experiencing, an AppDomain restart. So unless you do as Espo has said and use svn export, you'll see this issue.

Would it be easier to write a 2 line batch file that svn updates a local copy and then copies the files across?

Answer 3

You probably want to add the "Bin" directory to your svn:ignore list; it should not be committed anyway as it contains compiled code, not source code.

In any case as your final deployment "svn export" is probably a better choice, as others have noted.

Answer 4

An app pool recycle should not be that big a deal. Is your issue perhaps that your users are losing their session when this happens? If so, switch to StateServer or SQLServer sessions instead of using InProc.