dll hell

  • Thread starter Thread starter Peter Kirk
  • Start date Start date
P

Peter Kirk

Hi

I have some classes which use log4net (ver 1.2.9.0). These classes run
inside a cms-framework - which apparently also uses log4net internally, but
version 1.2.0.3. This causes problems with my classes - I get an error like:
Could not load file or assembly log4net, version=1.2.9.0, culture=... The
located assembly's manifest definition does not match the assemply
reference. (exception from HRESULT: 0x80131040).

If I replace the cms's version of log4net.dll with the one I use, then the
cms complains (same sort of error as above but with different dll version).

How can I get the cms and my classes to use their own versions of
log4net.dll?

Thanks,
Peter
 
Peter Kirk said:
Hi

I have some classes which use log4net (ver 1.2.9.0). These classes run
inside a cms-framework - which apparently also uses log4net internally,
but version 1.2.0.3. This causes problems with my classes - I get an error
like: Could not load file or assembly log4net, version=1.2.9.0,
culture=... The located assembly's manifest definition does not match the
assemply reference. (exception from HRESULT: 0x80131040).

If I replace the cms's version of log4net.dll with the one I use, then the
cms complains (same sort of error as above but with different dll
version).

How can I get the cms and my classes to use their own versions of
log4net.dll?
Click to expand...

Install both versions of log4net in the GAC side-by-side, or create a policy
file to direct the loader to load 1.2.9.0 whenever 1.2.0.3 is requested.

Read this

..NET Framework: Building, Packaging, Deploying, and Administering
Applications and Types—Part 2
http://msdn.microsoft.com/msdnmag/issues/01/03/BuildApps2/

David
 
David Browne said:
Install both versions of log4net in the GAC side-by-side,
Click to expand...

Unfortunately, to install in the GAC the log4net assemblies must have strong
names. Only version 1.2.9.0 has a strong name. Another problem would be that
(as far as I have been able to understand it anyway), the .net runtime only
checks the major.minor version numbers when loading from the GAC - and they
are the same in both cases here (even though the two versions of log4net
appear to be incompatible).
or create a policy file to direct the loader to load 1.2.9.0 whenever
1.2.0.3 is requested.
Click to expand...

Can you explain a bit more about "policy file". Is this the same as
assemblyBinding? In that case I think the assemblies both need to have
strong names don't they?
Read this

.NET Framework: Building, Packaging, Deploying, and Administering
Applications and Types-Part 2
http://msdn.microsoft.com/msdnmag/issues/01/03/BuildApps2/
Click to expand...


Thanks,
Peter
 
There are a couple of options I can see.

1. If the CMS publisher has not restricted this option, you can specify, in
config, that it should use newer versions. This is a workaround, not a pill.
Possible failure points:

a) Interfaces have changed in log4net
b) Publisher has restricted this option

2. Switch to using the older version in your application. This is the safest
option, although you may lose functionality, which may be unacceptable.

3. Move your logging to a web service (ASMX or Remoting). The danger here is
you are adding a layer, but this gets around the problem by wrapping it in
another "application". This is a very SOA type implementation for logging
and is largely a bandaid.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
 
Back
Top