asp.net - Will my website assemblies always run in the same AppDomain together? -
i have built 2 different user control libraries use on sharepoint 2007 site. 1 provides user controls ecommerce functions, other account dashboard. both of them make use of authenticated users/site membership.
so i've built assembly called webaccounts.dll contains of basic, common, account functionality such logging in, logging out, retrieving member data , storing pieces of member data in session. both ecommerce library , account dashboard library reference account , build on top of it. instance, both provide own version of login/logout control captures user credentials, , pass them along webaccounts authenticated , store authenticated member object in session.
where i'm lost how iis creates appdomains , instances of these libraries. if place 3 assemblies in bin of sharepoint site, user guaranteed using instances of 3 assemblies contained within same appdomain? or on 1 page might user's request process in appdomain ecommerce , webaccounts loaded, , next request process in appdomain dashboard , webaccounts loaded?
point in case: webaccounts provide login , logout events uses assemblies can perform server-side actions in response. i.e. can user using ecommerce, adds objects session state, click "log out" on dashboard user control, in turn calls logout() in webaccounts.dll, fire "loggedout" event in webaccounts.dll, , guaranteed instance of ecommerce using (which has subscribed event on application startup) able handle event remove items session state? example if webaccounts defines static variable, ecommerce , dashboard use same variable navigate between pages of site? since these run under same application starting point, sharepoint site, in same bin together, seems should in same appdomain , should work?
other concerns gac, , scalability. first, assemblies in gac, because it's lot easier use them in sharepoint way. expectation loading them gac instead of bin wouldn't change way appdomains set up. second, if move server farm, still work. given we're using sql based session state, think part work. know accessing static variable break down request request because there multiple instances of variable on different servers, variable reliably set , retrieved both user control libraries during single request? webaccounts assembly horrible idea web site?
during normal operations there 1 worker process , 1 app domain each web site (assuming using 1 web site per app pool - i'm not aware of reason of not doing that).
this means code loaded share same static variables , same application state.
during recycling there can multiple workers , multiple app domains contents structured in same way.
i don't know how sharepoint operates. probably, runs single web site. therefore, code loaded hosted in same app domain.
the litmus test see whether 2 libraries share same app domain whether have access same httpcontext.current.
the gac not play role here. there no such thing "an instance of dll". there 1 dll , can loaded different app domains.
i know accessing static variable break down request request because there multiple instances of variable on different servers
that true.
but variable reliably set , retrieved both user control libraries during single request
during single request there ever 1 app domain involved in processing it. no exceptions. whatever code loaded in app domain can take part. long sharepoint decides load code (and call it) you're set.
i webaccounts provide login , logout events uses assemblies can perform server-side actions in response.
the key question is: there causes dlls hook events? ensure that case. not concern whether dlls loaded or where. concern whether code in them being called allow them subscribe events.