EntLib 3.1 / 4.1 deployment "side-by-side"... How??

Topics: Building and extending application blocks, Enterprise Library Core, General discussion
Nov 7, 2008 at 8:15 PM
I am currently overseeing a project where we are making use of both the Smart Client Software Factory as well as the Web Client Software Factory. Those two software factories have EntLib 3.1 dependencies... Without pursuing recompiling the factories and their guidance and the associated hassles that would come from that... I'm looking to simply allow those assets to make use of their existing 3.1 based references but having the new code being authored for the actual business logic / data access / etc... to make use of EntLib 4.1 (in particular Unity 1.2)....

To date, I've tried multiple approaches. I have to use a xcopy-based deployment strategy so any GAC-based solution wouldn't meet my needs. It seems I need a way for the 2 sets of DLL's to reside within the same "bin" folder effectively.  Obviously with filenames that conflict - this won't work.  So my approach has been to try and make use of assembly binding directives in the Web.Config / App.Config of the two applications...

I first tried the simple additon of a <probing privatePath="bin;bin\EntLib.3.1\;bin\EntLib.4.1\" /> statement ensuring the DLL's were copied into their respective sub-directories and not residing in the BIN folder itself. That didn't appear to work. From what I can tell... it will still make a "hit" based on the filename and in the case above... the 3.1 references might have worked but requests for the 4.1 codebase would fail... From what I read it finds a hit by name and regardless of being the "right" file it still counts it as being "found" and simply reports back that it is an invalid reference... without checking any further paths...

Next I looked into using true <dependentAssembly> entries... I thought for sure this was going to be my solution... but initial attempts thus far have failed... I'm not sure where to go next or whether I was close and missed some small detail...

Can anyone offer me a solution? I would hate to have to establish an entirely new project on EntLib 3.1 - and I have to use Unity 1.1 or 1.2 - of course preferring to start off with what is current... Not using Unity is not an option either....


Sample entries for 3.1 ...

<

 

dependentAssembly>

 

<

 

assemblyIdentity name="Microsoft.Practices.EnterpriseLibrary.Common.dll" publicKeyToken="b03f5f7f11d50a3a" />

 

<

 

codeBase version="3.1.0.0" href="EntLib.3.1/Microsoft.Practices.EnterpriseLibrary.Common.dll" />

 

</

 

dependentAssembly>

 

Sample entries for 4.1 ...

<

 

dependentAssembly>

 

<

 

assemblyIdentity name="Microsoft.Practices.EnterpriseLibrary.Common.dll" publicKeyToken="31bf3856ad364e35" />

 

<

 

codeBase version="4.1.0.0" href="EntLib.4.1/Microsoft.Practices.EnterpriseLibrary.Common.dll" />

 

</

 

dependentAssembly>

 





Nov 10, 2008 at 6:49 AM
Did you try adding <bindingRedirect> entries under each <dependentAssembly> entry?


Sarah B. Urmeneta   
Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com
Jan 22, 2010 at 9:02 PM

With the different guidance packages using different versions of the EL I'm very surprised that no one's specified a clear ( and hopefully concise ) way on how to do it.

If you wanted a version of one to supercede an older one, I could see where <bindingRedirect> might be useful, but remember, he ( and now I ) are saying "COEXIST".

In my case. I've got a WCSF application ( which  refers to EL 3.1 ) that talks to a BL ( EL 4.1 ) that talks to two different DL's ( one built with the Repository Factory - EL 4.1 ) and the other to the Original DAAB ( 2.0.2.0 ).

Other than GAC'ifying every dependent Assembly, I haven't found a relatively simpler way of segrating assemblies this way 

WCSF site 

     \ Bin

          \DLLS

                  \ EntLib_3.1

                  \ EntLib_4.1

                  \ EntLib_2.0

 

A way of segrating assemblies like this..should not require brain surgery skills to accomplish.