"Clément ESCOFFIER" <clement.escoffier@imag.fr> wrote in message
news:410a05ca$0$15270$636a15ce@news.free.fr...
> Hello,
>
> I have a little questions about Assemblies who are loaded in the shared
> Domain.
>
> When an AppDomain ( perhaps the Default Domain create for the executable
> ) want use a Shared Assembly ( who is in the shard domain ), how the
> assembly resolver find it ?
>
> And when appdomain find the assembly, the runtime copy the assembly in
> the appdomain or use it directly ?
>
> All transaction between the shared domain and a appdomain use .Net
> Remoting or its direct ?
>
> A last question :
> When an assembly is shared, and an appdomain load this assembly with a
> different security policy. Can the appdomain use this assembly or it
> must reload the assembly ( directly from the .dll or from the shared
> domain ? )
>
> thank you very much
>
> Clément

"David Levine" <noSpamdlevineNNTP2@wi.rr.com> wrote in message
news:ecAAUshdEHA.1764@TK2MSFTNGP10.phx.gbl...
> What do you mean by a shared domain and shared assemblies? Do you mean
> domain neutral assembies?
>
> These two links talk about domain neutral assemblies.
> http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx
> http://weblogs.asp.net/junfeng/
>
> If all you mean is that you want to load the same assembly into different
> appdomains, then that is straightforward. Each appdomain treats the
assembly
> as if it had never seen it before, so each can use its own binding
policies,
> security settings, etc. The assembly is not shared by the .net runtime.
The
> runtime does not copy the bits unless you have shadow copying enabled for
> that appdomain.
>
> To communicate between appdomains you must use some sort of inter-process
> communications, such as remoting.
>
> You must be careful to maintain the isolation between appdomains. Do not
> return references to assemblies or types defined in assemblies unless you
> understand the consequences. For example, returning a reference to an
> assembly in a cross-appdomain method call causes the same assembly to get
> loaded into both appdomains; if it cannot load the assembly then the
runtime
> throws an exception.
>
> You don't apply security to the assembly itself, but you can supply
> additional evidence when you load the assembly to set the top of stack
> security. Be advised that this evidence does not get used if the loaded
> assembly itself references and loads other assemblies (in v1.1). When a
> method call crosses assembly boundaries the runtime evaluates the
permission
> request using the evidence associated with the assembly. If the appdomain
> sets its own security policy it does not need to do anything different
when
> it loads the assembly - the policy in one appdomain does not affect the
> policy in a different appdomain.
>
> "Clément ESCOFFIER" <clement.escoffier@imag.fr> wrote in message
> news:410a05ca$0$15270$636a15ce@news.free.fr...
> > Hello,
> >
> > I have a little questions about Assemblies who are loaded in the shared
> > Domain.
> >
> > When an AppDomain ( perhaps the Default Domain create for the executable
> > ) want use a Shared Assembly ( who is in the shard domain ), how the
> > assembly resolver find it ?
> >
> > And when appdomain find the assembly, the runtime copy the assembly in
> > the appdomain or use it directly ?
> >
> > All transaction between the shared domain and a appdomain use .Net
> > Remoting or its direct ?
> >
> > A last question :
> > When an assembly is shared, and an appdomain load this assembly with a
> > different security policy. Can the appdomain use this assembly or it
> > must reload the assembly ( directly from the .dll or from the shared
> > domain ? )
> >
> > thank you very much
> >
> > Clément
>
>