Appdomain unloaded when a file in App_Code is modified

[jake]

I've seen many articles that claim the files in the App_Code directory are
treated in the same way as aspx-files in ASP 1.1. Well, this does not seem to
be the case, at least in Web Developer 2005 Express Beta2. If I change
anything in any of the class files residing in App_Code, the AppDomain is
unloaded and all application data, including all sessions, is lost. Is there
anything I can do to prevent this?

This undesired side-effect means that I still cannot make any changes in a
critical production site without informing the customer in advance and
running the service down at a predefined time. Aspx-files are still the only
files that can be modified at runtime without unloading the AppDomain.

Why can't the new assembly be loaded in the current AppDomain? And is this
going to change for the final release or is the feature by design?

[Curt_C [MVP]]

IIRC it's because these files need to be recompiled into the site DLL(s)
which means that the app is restarted.

--
Curt Christianson
site: http://www.darkfalz.com
blog: http://blog.darkfalz.com

"jake" wrote:

I've seen many articles that claim the files in the App_Code directory are
treated in the same way as aspx-files in ASP 1.1. Well, this does not seem to
be the case, at least in Web Developer 2005 Express Beta2. If I change
anything in any of the class files residing in App_Code, the AppDomain is
unloaded and all application data, including all sessions, is lost. Is there
anything I can do to prevent this?

This undesired side-effect means that I still cannot make any changes in a
critical production site without informing the customer in advance and
running the service down at a predefined time. Aspx-files are still the only
files that can be modified at runtime without unloading the AppDomain.

Why can't the new assembly be loaded in the current AppDomain? And is this
going to change for the final release or is the feature by design?

[Bruce Barker]

i really wouldn't use inproc sessions on a critical production server. as
several events can cause a recycle, in a critical site you should always be
able to recover lost sessions.

-- bruce (sqlwork.com)

"jake" <ja**@discussions.microsoft.com> wrote in message
news:41**********************************@microsof t.com...

I've seen many articles that claim the files in the App_Code directory are
treated in the same way as aspx-files in ASP 1.1. Well, this does not seem
to
be the case, at least in Web Developer 2005 Express Beta2. If I change
anything in any of the class files residing in App_Code, the AppDomain is
unloaded and all application data, including all sessions, is lost. Is
there
anything I can do to prevent this?

This undesired side-effect means that I still cannot make any changes in a
critical production site without informing the customer in advance and
running the service down at a predefined time. Aspx-files are still the
only
files that can be modified at runtime without unloading the AppDomain.

Why can't the new assembly be loaded in the current AppDomain? And is this
going to change for the final release or is the feature by design?

[sp3d2orbit]

Curt is right about causing DLL's to be recompiled. But you can still
avoid taking your site down. You have a couple of options:

1. Use non-inproc sessions. You can use another server or, better yet,
sql server to store session: http://idunno.org/dotNet/sessionState.aspx

2. Use a clustering solution. You can use Windows Load Balancer to map
two distinct computers to one ip address. Clients will get a session
that is "sticky" to one computer or the other. When you need to make
changes to an assembly you do it by updating one computer at a time.
Pull one computer out of the cluster by typing "wlbs stop" at the
command line. The computer will drain connections. This means that
current sessions will be preserved but new connections won't be
allowed. After 20 - 30 minutes the computer should be drained (wlbs
status). Make your changes, add the computer back to the cluster (wlbs
start) and repeat. Your site will run interrupted.

Matt Furnari

[jake]

Thanks for the fast reply. Yeah, I know that's what happens. However, a new
dll is also created when an aspx-page is changed. When the aspx-page is
modified, it is compiled into a new assembly that includes the modified Page
class. But instead of throwing away the AppDomain, it just loads the new
assembly in the same AppDomain. I am not exactly sure of the details, but
somehow the new assembly is then used instead of the old one. I checked
what's going on in the Temporary ASP.NET Files -directory when I modified an
aspx-page and executed it. The old version (App_Web_xxxx.dll) was renamed to
App_Web_xxxx.dll.delete and a new App_Web_yyyy.dll was created (xxxx and yyyy
seem to be just some random sequences). When I modified a class file in the
App_Code directory, new versions of both App_Web.dll and App_Code.dll were
created. The difference was that the old versions weren't renamed to .delete.

I still don't understand why the code in the App_Code directory can't be
handled in the same way as the code in aspx-pages. Couldn't the dll renaming
and other stuff be done in the same way as with aspx-pages? I know the old
versions can't be unloaded (at least in ASP1.1) so they consume some memory,
but it's the same with the compiled aspx-pages and I think it's the lesser of
two evils.

"Curt_C [MVP]" wrote:

IIRC it's because these files need to be recompiled into the site DLL(s)
which means that the app is restarted.

--
Curt Christianson
site: http://www.darkfalz.com
blog: http://blog.darkfalz.com

"jake" wrote:

I've seen many articles that claim the files in the App_Code directory are
treated in the same way as aspx-files in ASP 1.1. Well, this does not seem to
be the case, at least in Web Developer 2005 Express Beta2. If I change
anything in any of the class files residing in App_Code, the AppDomain is
unloaded and all application data, including all sessions, is lost. Is there
anything I can do to prevent this?

This undesired side-effect means that I still cannot make any changes in a
critical production site without informing the customer in advance and
running the service down at a predefined time. Aspx-files are still the only
files that can be modified at runtime without unloading the AppDomain.

Why can't the new assembly be loaded in the current AppDomain? And is this
going to change for the final release or is the feature by design?

[jake]

Inproc sessions are just one thing (we don't use inproc sessions in all
services). But we use a lot of in-memory caching and our systems include some
long running business processes that need to store intermediate results in
memory etc. Sure, some caching can be done using out-of-proc methods, but
sometimes inproc is the only feasible solution for performance reasons.

We run our services in separate IIS app pools (one site per app pool) and
the app pool is configured to never recycle or shutdown. I don't think we
have had a single unexpected recycle to date when using this method. The
servers are rebooted periodically, but usually it only needs to be done when
installing Microsoft updates.

jake

"Bruce Barker" wrote:

i really wouldn't use inproc sessions on a critical production server. as
several events can cause a recycle, in a critical site you should always be
able to recover lost sessions.

-- bruce (sqlwork.com)

"jake" <ja**@discussions.microsoft.com> wrote in message
news:41**********************************@microsof t.com...

I've seen many articles that claim the files in the App_Code directory are
treated in the same way as aspx-files in ASP 1.1. Well, this does not seem
to
be the case, at least in Web Developer 2005 Express Beta2. If I change
anything in any of the class files residing in App_Code, the AppDomain is
unloaded and all application data, including all sessions, is lost. Is
there
anything I can do to prevent this?

This undesired side-effect means that I still cannot make any changes in a
critical production site without informing the customer in advance and
running the service down at a predefined time. Aspx-files are still the
only
files that can be modified at runtime without unloading the AppDomain.

Why can't the new assembly be loaded in the current AppDomain? And is this
going to change for the final release or is the feature by design?