.NETGURU
Statically referenced assemblies are not loaded at startup ... Why
Messages   Related Types
This message was discovered on microsoft.public.dotnet.framework.clr.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
Post a new message to this list...

Bob (VIP)
have .NET component Definitions.dll which contains only definition of
interface IComm.
I also have components which contain implementations of that interafce.
Let say components are Comp1.dll, Comp2.dll and Comp3.dll. These components
contain 3 different classes Class1, Class2 and Class3 respectively. Each of
these
classes is different implementation of IComm interface.

I also have an app which statically reference components Comp1.dll,
Comp2.dll and Comp3.dll.
The app iterates through loaded into default application domain assemblies,
discovers the types these assemblies implement and creates list of types
which are implementation
of IComm interface. Then the app instantiates these types but cast them to
IComm and use them
like they are instances of IComm. For example:

m_pCommInt = dynamic_cast<IComm*> (Activator::CreateInstance(NewType ) );

In other words in the code of my application there are no explicit
references to classes Class1,
Class2 and Class3.

The problem I face is that when I launch my application, the assemblies
Comp1.dll, Comp2.dll
and Comp3.dll are not loaded into default application domain at startup,
even though they
are statically referenced in the project. Somehow framework get confused and
think that
since app doesn't explicitly instantiate classes Class1, Class2 and Class3,
the corresponding
assemblies Comp1.dll, Comp2.dll and Comp3.dll are not required and doesn't
load them.

Can anyone comment or clarify whether this is expected behavior? Is there
any way to force
framework to load statically referenced components into default application
domain?
I know that I can dynamically load assemblyby calling Assembly::Load, but
this is not
what I want. I am talking about case when assembly statically referenced in
the project.

Is it wrong approach: statically reference assemblies and then trying to
figure out
which types they support?

Reply to this message...
 
    
Jon Skeet [C# MVP] (VIP)
Bob <Click here to reveal e-mail address> wrote:

<snip>

[Original message clipped]

Yup.

> Can anyone comment or clarify whether this is expected behavior?

It's certainly expected by me - lazily loading assemblies improves
start-up time, just as not initializing types until they're needed
improves assembly loading time.

[Original message clipped]

Well, you can find the referenced assemblies using
Assembly.GetReferencedAssemblies, and then load each of them.

[Original message clipped]

Well, I'd do it dynamically, but if you definitely know at compile-time
what's going to be needed, that's fine. (Assuming the compiler keeps
the reference in there, of course. There's a chance a "smart" compiler
may decide to remove an unused reference entirely. It depends on the
language, I suspect.)

--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Reply to this message...
 
 
System.Reflection.Assembly




ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
Ad


Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews
.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT
Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project
FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.
Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials
 
ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
 Copyright © ExamGuru, Inc. 2001-2006
Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification