MBR IT/.NET 247 : Statically referenced assemblies are not loaded at startup ... Why on microsoft.public.dotnet.framework.clr

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

MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

	Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
	Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com