Sharing Assemblies

  • Thread starter Thread starter Brandon
  • Start date Start date
B

Brandon

We have a group of applications and utilities that use some common assemblies
that we have put together. Currenlty, we deploy these common assemblies to
the directory that each application/utility is in.

We are curring going through another round of trying to optimize memory
utilization. My understanding is that shared assemblies get loaded once, and
shared to all who access them - but I'm guessing that the fact that we have a
copy of the dll in each folder negates this benefit of sharing assemblies,
and that we have multiple copies of the same assembly loaded when all of the
apps/utilitys are running at the same time. Is this true? If so...

I am looking to improve this situation. From what I have read about using
GAC, I think it's more than we really want to mess with. We don't care to
have multiple versions of the same dll installed - when we update one of
these assemblies, we generally deploy a copy of it to each directory where it
is in use We also don't care to have to deal with cleaning up the old
versions to keep from wasting on-device storage.

Are there any other options? What if we establish a directory where we
manage all common assemblies, and then all of our apps/utilities just have to
know to load them at that specific location - is this what Assembly.Load() is
for? Will this accomplish the goal of saving memory? Any gotchas?
 
Put them in a common folder and GAC them. Not sure why you're averse to it.
It's really simple and provides the sharing you want.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
It looks like it removes the dll and recreates it in the Windows folder with
the "GAC...dll" name. This does not mesh well with our file management
system, which is built to manage files in place - if they disappear, they get
retransferred. Also, we update these assemblies frequently, and we wanted to
avoid the accumulation of multiple versions. We can take a look at it again
if you think there's something I'm missing.
 
Then just put all of them in the Windows folder. You have only one copy of
each and they wouldn't be GACed. Alternately you can add the folder where
you are putting them to the system loader path in the registry. That
probably requires a restart/soft reset the first time through.
 
I actually tried throwing them in the Windows folder, and the app did not
find them...is there some other requirement there (strong name?)? I have not
yet delved into what it means to strongly name the assembly, if that is a
requirement.

Thanks for your input.
 
No, strong naming isn't required. If it can't find the assembly local, it
should follow the loader path and look in \Windows (and any other extensions
to the loader path). Strong naming would help the CLR to know it's looking
at the right one for loading.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
 
The CLR will never look in the Windows path to load assemblies which probebly
explains why this doesn't work for you. It will look at in the GAC if the
assembly is strong named which happens to be Windows folder on mobile devices
but not Windows explicitly. The CLR will look in the GAC first if strong
named, otherwise the local directory and sub directories depending on whether
the assembly contains non-neutral culture information.

Not sure if probing is supported on devices, never used it. If it is, you
could set the probe to Windows.

The above is different of course to native code.
 
From this article:
http://blogs.msdn.com/stevenpr/archive/2005/01/05/347353.aspx
It sounds like weak naming and path-based references should do what I am
trying to do. My plan is to have

....\appl\myapp\myapp.exe

use Assembly.Load() to load just one assembly from

....\appl\shared\

and from that point on, probing should automatically look in that directory
for any further references it can't resolve in the application base
directory. I'll update on how this goes.

Obviously, I can test, but would you expect this to have the desired result
of not having each of 3-6 .NET processes load their own copy of the assembly
(process A runs first and loads the assembly into the memory-mapped file
space, process B should starts next, and should just use the copy already
loaded), reducing the overall physical memory footprint?

Sub-question: if process A sets a value for a static property for a class
instantiated from the assembly, and process B sets the same value...they each
have their own instance of the object...they won't conflict, with they?
 
Obviously, I can test, but would you expect this to have the desired
result
of not having each of 3-6 .NET processes load their own copy of the
assembly
(process A runs first and loads the assembly into the memory-mapped file
space, process B should starts next, and should just use the copy already
loaded), reducing the overall physical memory footprint?
Click to expand...

You'll save on installation footprint, but I doubt you'll save any load
footprint. Managed assemblies are loaded as memory-mapped files, so the
whole thing is never loaded anyway. The load footprint will be the JIT
compiled code, which will be the same if they come from the same or separate
file instances. There may be some minor metadata savings, but I'm betting
it's very small if it exists at all.
Sub-question: if process A sets a value for a static property for a class
instantiated from the assembly, and process B sets the same value...they
each
have their own instance of the object...they won't conflict, with they?
Click to expand...

Processes get their own data segments, so no, they won't conflict.
 
Back
Top