"VictorG" wrote:

> So it appears to be initializing WPF UserControls, there are four in
> the assembly being loaded. These are hosted on a WinForm using the
> ElementHost for interop. Still puzzled as to why, when loaded in the
> default domain, this would take so long?
>
>
> On Mar 25, 11:58 am, VictorG <grippiconsult...@yahoo.com> wrote:
> > On Mar 25, 9:21 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote:
> >
> >
> >
> >
> >
> > > VictorG wrote:
> > > > I created a loader class in a separate assembly. It has a .ctor that
> > > > calls ExecuteAssemblyByName in the other domain.
> >
> > > > I just tried it but it has no effect. Still ~6.0 seconds to load the
> > > > window.
> >
> > > > This leads me to believe it is inherent in one of the types I am
> > > > trying to load, although when loaded in the default domain, it only
> > > > takes two seconds?
> >
> > > > Any other ideas?
> >
> > > Well, you could force your loader class to access those types so the type
> > > initializers run, and benchmark the time for each. Normally you need a
> > > bunch of iterations for benchmarking and type initializers aren't really
> > > conducive for that, but you ought to be able to isolate a six second delay
> > > with only one iteration.
> >
> > > Were you able to verify that it is the call to ExecuteAssemblyByName that is
> > > taking so long, not the cross-domain method call to the loader?
> >
> > > You could even hit the break button in the debugger during the delay and see
> > > where you end up.
> >
> > Yes, the delay is in the call to ExecuteAssemblyByName. I am also
> > looking at the fusion log but cannot determine which assembly, if any,
> > is taking longer to load. I will try the break button and report
> > back. Thanks.
> >
> >
> >
> >
> >
> > > > On Mar 21, 12:00 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote:
> > > >> VictorG wrote:
> > > >>> On Mar 21, 7:48 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospam>
> > > >>> wrote:
> > > >>>> VictorG wrote:
> > > >>>>> Hello,
> >
> > > >>>>> I'm wondering why ExecuteAssemblyByName takes aprox. 6 seconds to
> > > >>>>> load
> > > >>>>> a small assembly and display a Winform, when it only takes 1.8
> > > >>>>> seconds
> > > >>>>> to load the same assembly in the default domain?
> >
> > > >>>>> CLR is already loaded in the process so using an appdomain s/b
> > > >>>>> faster?
> >
> > > >>>>> Are there any known optimizations to speed this up?
> >
> > > >>>> Most probably the security evidence and all is created in the
> > > >>>> default domain, and now you get cross-domain marshalling
> > > >>>> continually.
> >
> > > >>>> Why not make a helper which would run in the new appdomain, make a
> > > >>>> copy of the args, create the new Evidence object, then call
> > > >>>> ExecuteAssemblyByName?
> >
> > > >>>>> (assembly is not strong named)
> >
> > > >>>>> FAST:
> > > >>>>> AppDomain.CurrentDomain.ExecuteAssemblyByName(fullName, new
> > > >>>>> System.Security.Policy.Evidence(), args);
> >
> > > >>>>> SLOW: (called from the default app domain like above)
> > > >>>>> newDomain.ExecuteAssemblyByName(fullName, new
> > > >>>>> System.Security.Policy.Evidence(), args);
> >
> > > >>>>> Any help is greatly appreciated.
> >
> > > >>>>> Thanks,
> > > >>>>> Victor Grippi- Hide quoted text -
> >
> > > >>>> - Show quoted text -
> >
> > > >>> Thanks for your reply.
> >
> > > >>> Do you mean to invoke a method on a helper class in the other
> > > >>> domain, using a CrossAppDomain delegate? I've used this before but
> > > >>> the signature for the delegate does not allow for any parameters? I
> > > >>> don't want to call any of the CreateInstance methods, since I'm
> > > >>> trying to avoid binding to any types in the other app domain, so it
> > > >>> can be unloaded later.
> >
> > > >> I meant to load one of the types from the primary app domain, into
> > > >> the secondary app domain. That assembly is permanently loaded anyway.
> >
> > > >> Its constructor can then call CurrentDomain.ExecuteAssemblyByName.
> >
> > > >>> I tried using the LoaderOptimization attribute on the Main function,
> > > >>> to allow app domain sharing of code pages, but it still takes 6
> > > >>> seconds to load the assembly.
> >
> > > >>> I also tried passing a null Evidence argument but this had no
> > > >>> effect. Is there a way to turn off security since I am trying to
> > > >>> load a known trusted assembly?- Hide quoted text -
> >
> > > >> - Show quoted text -- Hide quoted text -
> >
> > > >> - Show quoted text -- Hide quoted text -
> >
> > > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
>