views:

185

answers:

4

In building an ASP.NET 3.5 WAP, I'm always frustrated by the feeling that no matter how I "isolate" or "encapsulate" bits of logic or UI I'm still going to bring down the whole site any time I need to update a single line of code. I may be misunderstanding how ASP.NET handles changes in the "bin" directory, but given the number of "why is my AppDomain unloading?" messages in the various groups this still seems like something to avoid.

Does anyone have any guidance and/or frameworks to truly modularize an ASP.NET 3.5 WAP so that logic and pages can be added/updated "in flight"? I Googled System.AddIn a bit, but it seems to be focused on WPF applications.

Thanks for your help!

James White

+1  A: 

This is really hard to achieve since .NET doesn't support unloading a type that has been loaded into the app domain.

One way to do it is playing around with app-domains, or having WCF do it for you.

Another would be implementing ayende's hod code swapping.

A third way would be putting logic in the dynamically compiled part (the ASPX). However the app will restart after a configurable amount of changes.

Cristian Libardo
I love Ayende's video, just need to track down an IoC container that serves up the latest version of a requested service and I'm good.
+1  A: 

Use two or more servers. When you need to upgrade, take one down, upgrade it, bring it up, take the other one down, upgrade it, bring it up.

It takes a bit of effort to be able to do this - having both versions running at the same time - as database changes etc can be tricky. But the same effort also pays off in being able to roll changes back, perhaps host just a few users on an "experimental" server etc. Not to mention horizontal scaling being a good thing in general :)

Jon Skeet
+1  A: 

You can take a different approach here, which is to make it that an AppDomain restart doesn't affect usability of the site.

To do that, move session out of process, or stop relying on session entirely.

If you do this, an appdomain restart isn't a big deal, and you are prepping your application for easier scalability across clusters if you ever get to that point.

FlySwat
A: 

Just an added thought, but I bet that was what that whole "COM+" bit allowed (save for shared hosts). Breaking logic down into little stateless sausage factories probably allowed for smooth fix-in-flight operations.