Anything Wrong With "preloading" Assemblies?

I am needing to create a sort of "plug-in architecture" whereby different
Web sites I maintain on the same server have slightly different
functionality. Some Web sites will need to use the functionality in some
assemblies, while others will get similar functionalilty from different
assemblies.

What I was thinking about doing - and I'd apprecaite your feedback on this -
is to load the assemblies required by a particular site into the site's
default application domain, and do this loading during Application_Start. I
would load the assemblies via Reflection (e.g., Assembly.Load()).

Two benefits of doing it this way:
1. I can have all the logic in one place... this is the logic that
determines which assemblies to load for the current site.

2. A minor benefit is that when members from a given assembly are eventually
required, the assembly is already loaded, thereby helping with runtime
performance.

Are there any significant downsides to doing it this way, or reasons I
should not preload these assemblies? Any "gotchas" I should account for?

Thanks!

Re: Anything Wrong With "preloading" Assemblies?

Hello Robert

i dont see any problems here. The only thing to discuss is the preload
instead of load on demand. But that depends on your specific
architecture. But i am looking forward to read some other opinions about
that.
Greetings,
holger

> I am needing to create a sort of "plug-in architecture" whereby different
> Web sites I maintain on the same server have slightly different
> functionality. Some Web sites will need to use the functionality in some
> assemblies, while others will get similar functionalilty from different
> assemblies.
>
> What I was thinking about doing - and I'd apprecaite your feedback on this -
> is to load the assemblies required by a particular site into the site's
> default application domain, and do this loading during Application_Start. I
> would load the assemblies via Reflection (e.g., Assembly.Load()).
>
> Two benefits of doing it this way:
> 1. I can have all the logic in one place... this is the logic that
> determines which assemblies to load for the current site.
>
> 2. A minor benefit is that when members from a given assembly are eventually
> required, the assembly is already loaded, thereby helping with runtime
> performance.
>
> Are there any significant downsides to doing it this way, or reasons I
> should not preload these assemblies? Any "gotchas" I should account for?
>
> Thanks!


--
Holger Kreissl
..NET Software Developer
http://kreissl.blogspot.com/

Re: Anything Wrong With "preloading" Assemblies?

RE:
<< The only thing to discuss is the preload instead of load on demand. But
that depends on your specific architecture >>

In my case I have a few HTTP handlers per Web site that are not traditional
..ASPX pages (they don't even inherit Page). It is the selection of the
particular subset of special handlers [to load for a given site] that I
would like to perform during Application_Start. For me this selection is the
primary motivation. I have to do it somewhere and would prefer to NOT run
that logic potentially many times, which would be the case if I were to go
with a load-as-needed implementation. The performance of having them pre
loaded is of secondary importance, although it's certainly a benefit.

-RC

Re: Anything Wrong With "preloading" Assemblies?

I'm not all warm and fuzzy about this approach to tell you frankly. I think
your working set will grow large which will result in page faults and
performance issues. You can't really unload an assembly so it sits around
hogging memory and resources. Anyway you go with modern code would isolate
the logic so your benefit in item 1 is not a distinct advantage.

I'd suggest a redesign to work around the working set issue. Use inheritance
and a class hierarchy to 'point' to the functionality. When it is required,
you would load it inside an app domain. app domains can be unloaded and are
a lot lighter than assemblies so essentially, you would have one assembly
that knows where the functionality of each plug in is.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------




"Robert Cramer" wrote in message
news:OYFnPCsoIHA.4912@TK2MSFTNGP03.phx.gbl...
> I am needing to create a sort of "plug-in architecture" whereby different
> Web sites I maintain on the same server have slightly different
> functionality. Some Web sites will need to use the functionality in some
> assemblies, while others will get similar functionalilty from different
> assemblies.
>
> What I was thinking about doing - and I'd apprecaite your feedback on
> this - is to load the assemblies required by a particular site into the
> site's default application domain, and do this loading during
> Application_Start. I would load the assemblies via Reflection (e.g.,
> Assembly.Load()).
>
> Two benefits of doing it this way:
> 1. I can have all the logic in one place... this is the logic that
> determines which assemblies to load for the current site.
>
> 2. A minor benefit is that when members from a given assembly are
> eventually required, the assembly is already loaded, thereby helping with
> runtime performance.
>
> Are there any significant downsides to doing it this way, or reasons I
> should not preload these assemblies? Any "gotchas" I should account for?
>
> Thanks!
>
>

RE: Anything Wrong With "preloading" Assemblies?

This --
http://www.eggheadcafe.com/articles/20041204.asp
--might give you some ideas along this line of thought. The original concept
was developed by my friend and fellow MVP, J. Ambrose Little.
-- Peter
To be a success, arm yourself with the tools you need and learn how to use
them.

Site: http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://ittyurl.net


"Robert Cramer" wrote:

> I am needing to create a sort of "plug-in architecture" whereby different
> Web sites I maintain on the same server have slightly different
> functionality. Some Web sites will need to use the functionality in some
> assemblies, while others will get similar functionalilty from different
> assemblies.
>
> What I was thinking about doing - and I'd apprecaite your feedback on this -
> is to load the assemblies required by a particular site into the site's
> default application domain, and do this loading during Application_Start. I
> would load the assemblies via Reflection (e.g., Assembly.Load()).
>
> Two benefits of doing it this way:
> 1. I can have all the logic in one place... this is the logic that
> determines which assemblies to load for the current site.
>
> 2. A minor benefit is that when members from a given assembly are eventually
> required, the assembly is already loaded, thereby helping with runtime
> performance.
>
> Are there any significant downsides to doing it this way, or reasons I
> should not preload these assemblies? Any "gotchas" I should account for?
>
> Thanks!
>
>
>
>