CLR Dll loading behavior

[Raja Banerjee]

Whether the entire Dll is loaded into memory or not has become a design
criteria in my current project. If with .NET the entire DLL is not
loaded I will create projects to compile into large DLLs. Else I will
split up the logic to create as many DLLs as possible.

I always believed that DLLs were loaded at runtime "as and when needed"
in the pre .NET world. Hence if a new class from a DLL needed to be
instantiated the entire DLL needed to be loaded into memory.

Recently I was advised that with .NET the CLR can load only the
information needed for one class to work( Its dependencies , methods
and everything else you get from the metadata)

With my current understanding of the framework I was not able to pull
up much information from MSDN. Any comments or pointers on this topic
is greatly appreciated.

Thanks
Raja

 

[David Browne]

Whether the entire Dll is loaded into memory or not has become a design
criteria in my current project. If with .NET the entire DLL is not
loaded I will create projects to compile into large DLLs. Else I will
split up the logic to create as many DLLs as possible.

I always believed that DLLs were loaded at runtime "as and when needed"
in the pre .NET world. Hence if a new class from a DLL needed to be
instantiated the entire DLL needed to be loaded into memory.

Recently I was advised that with .NET the CLR can load only the
information needed for one class to work( Its dependencies , methods
and everything else you get from the metadata)

With my current understanding of the framework I was not able to pull
up much information from MSDN. Any comments or pointers on this topic
is greatly appreciated.

This should not normally be a design criterion. The parts of a DLL which
you do not access will remain paged out to disk, and managing multiple DLL's
is not worth saving a little memory when you load one.

But, to answer your question, the entire DLL is loaded, but the code is JIT
compiled only on on demand, so it's a little of both.

David

 

[Raja Banerjee]

Thanks David,

I will not have to split up to smaller DLLs in that case.

-Raja

 

[Lloyd Dupont]

Don't try to cleverer than the System
As David Browne said, unused part of the DLL are paged out on the disk.
So save yourself lot of maitenance and make big DLLs!!

On the other hand I, myself, most of the time split my app in at least 3
DLLs
1 for the data, 1 for common GUI control, 1 for the app.
To enforce MVC development...