May 27, 2010 at 9:49 AM
Edited May 28, 2010 at 8:52 AM
Thanks for taking the time to reply. I have more questions :)
In our environment we chose to re-bundle EntLib in a framework of our own making way back at V3 (I think). It is signed with our keys and the version number tweaked for our own use. This has been rolled out to 1000's of desktops across the company.
As things are fixed a new version is rolled out but the old versions remains for existing apps because of the cost of regression testing and paranoia! So we have ones versioned as 1.1, 1.2, 1.3 and 1.4 targetted at CLR 1.1. We rebuilt and enhanced
for CLR2 and rolled out a 2.0, there may also be a 2.1. Now we have CLR4 and a framework/entlib targetted at that maybe.
So the clients could have 6 or more copies of Entlib DLL's with version numbers 1.1, 1.2, 1.3, 1.4, 2.0, 2.1, 4.0
In fact the entlib in 1.1/2/3/4 will be virtually indentical except for the version number. 2.0 has Entlib 3.1 and for 2.1 we would have incremented Entlib to 3.2 (for our own use!)
I believe these are all in the GAC.
A new development comes along and uses 4.0. Let's say it drags in an old 2.1 assembly because we don't have the source and can't recompile it, and it starts logging through Entlib. Which Entlib DLL will be brought in? My guess would be 2.1. But
what if the parent app (CLR4) has already logged things, it will have brought in logging V4 so would the old DLL use that? I can't see how it can.
Perhaps because, as you say, commonservicelocator is just interface definitions and I guess references very few (if any) custom V2 assemblies, it is not such an issue.
Perhaps the commonservicelocator project could release a version that targets .NET 4. That would be quite easy (?) and make life easier :))