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" <A@xxxxx> wrote in message news:OYFnPCsoIHA.4912@xxxxxxxxxxxxxxxxxxxxxxx
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!


.



Relevant Pages

  • Re: Anything Wrong With "preloading" Assemblies?
    ... 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. ... Are there any significant downsides to doing it this way, or reasons I should not preload these assemblies? ...
    (microsoft.public.dotnet.framework.aspnet)
  • Side By Side Execution
    ... We have an application in which all assemblies have version 1.5.0.0. ... After client wanted some changes we changed few of the functionality ... We made one installation which used to backup 1.5.0.0 ver. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Performance for lots of assemblies
    ... We have a large insurance web application that implements the entire ... personally shy away from designing so many assemblies unless they are ... functionality in 35 other assemblies and it is a complex operation, ...
    (microsoft.public.dotnet.framework.performance)
  • RE: Anything Wrong With "preloading" Assemblies?
    ... Some Web sites will need to use the functionality in some ... assemblies, while others will get similar functionalilty from different ... would load the assemblies via Reflection ... A minor benefit is that when members from a given assembly are eventually ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: C++ type friend functionality in C#
    ... assembly into other assemblies, but this could prove to be cumbersome. ... In C++ the friend keyword provided this functionality. ... > Howard Swope ...
    (microsoft.public.dotnet.languages.csharp)