VirtualPathProvider and Application Restart

  • Thread starter Thread starter Sriram Srivatsan
  • Start date Start date
S

Sriram Srivatsan

Hi

We are trying to build an application where we render some of the .aspx
pages from the database using a class derived from
System.Web.Hosting.VirtualPathProvider. Users configure the contents of the
page at runtime via the web interface and we do a XSLT transformation and
store the contents of the .aspx pages in the database. The .aspx pages are
hooked to a well known code behind in an assembly that is deployed as a
assembly in the bin folder of the web site.using the @Page inherits
attribute. None of the contents are wired up using the autoeventwireup =
true but the code behind is a generic class that is written in such a way
that it has the intelligence to subscribe to events etc.

This approach is pretty similar to what is given here:

http://kbalertz.com/910441/virtual-providers-dynamically-compile-content-virtual-paths.aspx.

The PROBLEM! Asp.NET worker process restart. This depends on the entry in
the web.config file "numRecompilesBeforeAppRestart".

We want to avoid the asp.net worker process to restart itself as other
users of the application would loose the session state (which is In-Proc at
the moment) when the asp.net worker process unloads the application domain.

We use .NET framework 2.0 and VS2005 to do all this along with SQL Server
2005.

A couple of things that I already know may hack this up (dont want to do)

1. I can increase the numRecompilesBeforeAppRestart -- but this is
probably not a good idea since this would not make the problem go away.
Users would still experience this problem whenever asp.net does restart
itself.
2. I can make the session stored in the state server and write a back end
job to remove the session; or write a HttpModule to somehow remove the
session from the database -- this is a big performance hit as sessions
stored in the database would make things slower
3. I could as an alternative, dynamically load controls on the page.,
instead of doing things the way we do now. However, this would again
degrade performance and also increase complexity.


What we dont know

1. Is this approach conceptually flawed or is this ok? If so what are we
missing out? (The GetFileHash() override implementation of the
VirtualPathProvider that we have right now returns a new hash code each time
the contents of the database for the .aspx changes. We return a null for the
GetCacheDependency since we cant have a dependency to detect if the file
content of the .aspx has changed)
2. Is there a possibility of using the ClientBuildManager to precompile a
..aspx file when we generate the .aspx file -- maybe if the .aspx is already
precompiled, when the user requests for a page, the appdomain will NOT
unload itself? We do know that asp.net does a compilation when the user
requests for a page. What if we do the compilation using the
ClientBuildManager. And the user requests for the page AFTER the
application does the compilation?

Please let us know what you think if you can as we have tried to post here
to no avail and am not sure what I am missing anymore! I do have your phone
number but decided that it would be impolite to give you a call before
sending you an email.

http://forums.asp.net/p/1301629/2540774.aspx#2540774
http://www.opinionatedgeek.com/Blog/BlogEntry=000205/CommentEntry=006817/BlogEntry.aspx

Many thanks in advance. Anticipating your reply anxiously... I hope I am
clear as to what I wanted to convey...

Kris
 
I had sent an email to Walter Wang of Microsoft Online Community Support who
wrote this in reply to what I had asked. Thanks once again Walter., as now
atleast I can move forward. Since I have no other choice, I decided to move
the session state to the Database Server and move a lot of lightweight
things to a cookie. Also, I guess I will write a HttpModule to detect when
the user logs out etc to remove the record for the Session Id from the
Database.

Hi Sriram,


I'm afraid there's no way to workaround this automatic restarting. You see,
once an assembly has been loaded into the default AppDomain, there's no way
to unload it from the AppDomain. When you update an ASPX file, a new
assembly (maybe batch compiled with other changed ASPX files) will get
generated and loaded into the AppDomain. That means some obsolete copies of
assemblies are loaded in the AppDomain and wasting memory. The ASP.NET
engine has to restart the AppDomain once the numRecompilesBeforeAppRestart
limit is reached. Note the VirtualPathProvider is using the same compiling
engine, therefore this limitation also applies.


Best regards,

Walter Wang

Microsoft Online Community Support
 
Back
Top