Unity, Entlib, ServiceLocation Signing

May 26, 2010 at 4:29 PM
Edited May 27, 2010 at 8:50 AM

Hi Each time a new Entlib appears I have the same trouble tracking down how I create a complete set of DLL's that are signed with my companies strong name key.

I want to build a complete Entlib5, strong named with my key and targetting .NET 4 CLR

I can get the source to Entlib and Unity, tweak the project files and set the key BUT what about


How do I get this signed? Is it already signed with a trusted key and I just put in in the GAC?

Is it built for .NET 4 CLR?

any help appreciated, I can't be the only one wanting to do this thanks

May 26, 2010 at 5:21 PM
ServiceLocation dll code is available here on codeplex: http://commonservicelocator.codeplex.com The DLL is signed with a Microsoft key. It targets .NET 2.0, but works unchanged on .NET 4.0 (it's mostly an interface definition). I would strongly recommend against recompiling and resigning this DLL. The whole point is to be a common binary interface for multiple DI containers to use. If you recompile and resign, you will break every container adapter out there. Just out of curiosity, why do you want to rebuild targeting .NET 4.0? I hear the occasional person wanting to do this, but I've never heard an actual reason other than "it's the latest and greatest."
May 26, 2010 at 11:26 PM
Edited May 27, 2010 at 12:16 AM

I am happy to be talked out of rebuilding everything in .NET 4 but I was under the impression that if we want to exploit the new features of V4 we have to compile everything in V4. Are you saying we can mix V2 and V4, I thought there was a new CLR?

If we have some assemblies targeting V2 (like this one) then you can get into trouble with it pulling in V2 versions of DLL's you have rebuilt in V4 don't you?

I quote from this article for more info: http://msdn.microsoft.com/en-us/magazine/ee819091.aspx
also :http://blogs.msdn.com/clrteam/archive/2009/06/07/in-process-side-by-side-part-2-common-in-proc-sxs-scenarios.aspx

Library Developers and Consumers: In-Proc SxS does not solve the compatibility problems faced by library developers. Any libraries directly loaded by an application—either via a direct reference or an Assembly.Load*—will continue to load directly into the runtime and AppDomain of the application loading it. This means that if an application is recompiled to run against the .NET Framework 4 runtime and still has dependent assemblies built against .NET 2.0, those dependents will load on the .NET 4 runtime as well. Therefore, we still recommend testing your libraries 
against all version of the framework you wish to support. This is one of the reasons we have continued to maintain our high level of backward compatibility.

So this is saying I can run this DLL targetted to .NET V2 within V4 and it will just work?  My concern is if this DLL (say) referenced Fred.DLL V2 that has now been built for V2 and V4. Perhaps the V4 has already been loaded or may be loaded by the parent app later, would this DLL pull in the V2 version? Meaning we have both in memory or worse the v4 code starts using the v2 assembly?

Imagine how this might cascade through mutiple versions of Entlib DLL's getting loaded.  Perhaps the SQLData class, a V2 DLL writes to SQL and pulls in the V2 Entlib DLL. The rest of the code is running the V4 version.  

What may happen with mixed DLL versions all logging through the Entlib block with 3 versions of entlib installed (maybe in the GAC)

I just don't want trouble along the road




May 27, 2010 at 4:45 AM
There is no free lunch, of course, you'll need to test on the target framework you'll be running on. In general, you solve this one through deployment - if you only deploy the DLL that targets V4, that's the one that'll get loaded (assuming version #'s and public key tokens line up, of course). It's going to be difficult to run multiple versions of Entlib in one process anyway, even if you were on the same CLR. Recompiling for V4 won't affect this in any way, except by making it worse by adding yet another assembly version.

Again, there's nothing stopping you from doing this, other than, as I said, I strongly recommend against rebuilding the ServiceLocator DLL for the compatibility reasons I mentioned above. But you don't gain anything either from what I know.

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 :))

thanks again