Microsoft.Practices.Unity.dll breaks other installed apps

Oct 15, 2014 at 3:34 PM
Hello,

First, let me just say that I love the extension and apps. The question I have is not that your extension is broken, but when it installs, it breaks other modules I have on our site. I am hoping you can help me with a work around, as I have no way to update the 2 modules (no source code, etc) that get broken.

The problem is your extension installs Microsoft.Practices.Unity.dll that happens to be a newer version (2.1.505.2) that what the 2 older modules (extensions) use (2.0.414.0).

So the basic question is… Is there are way for me to install your extension, while still keeping the older versions of that dll?

Thank you,
Dave Green
Coordinator
Oct 15, 2014 at 3:57 PM
Hi Dave

This is a tricky one - because shared DLLs always suck :(.

Normally, the older systems should also work with the newer ones, and I assume that MS doesn't introduce breaking changes in a version 2.1. So I'm guessing (but just guessing) that the real problem is not the version change (that this would work...) but that it's actually just special missbehaviour of the other modules not accepting a newer DLL.

This is all .net stuff, not really related to 2sxc. I have some suggestions, but I can't promise that anything works.
  • I know that you can somehow "redirect" DLLs. This is often done to redirect Razor 1 to the Razor 2 systems. Maybe you could add such a redirect to point the other system to the new DLLs. I don't know much about this, but you could give it a try.
  • You could also try to compile 2sxc with an older unity. I'm guessing that it would work, but would give you a unique installation which would be harder to debug if anything goes wrong.
Best,
Daniel
Oct 15, 2014 at 4:19 PM
Daniel,

Thanks for the quick response. I'll try to look into suggestion 1 as well, but would also definitely appreciate if you could do suggestion 2 for me. If all else fails, at least I would be able to use your awesome Google Tag app, which is REALLY what I am needing at the moment. :-)

Appreciate the help,
Dave
Oct 15, 2014 at 4:28 PM
i had to do that before, here is how i modified it for my dll in web.config, found the answer on stackoverflow somewhere kept the code, not the link

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="ControlReferencedByMyDll" PublicKeyToken="XXXXXXXXXXXXXXXX"/>
      <bindingRedirect oldVersion="1.0.0.0-9.9.9.9" newVersion="2.0.1.0"/>
    </dependentAssembly>
  </assemblyBinding>
</runtime>
Oct 15, 2014 at 5:02 PM
Edited Oct 15, 2014 at 5:28 PM
Nice... I'll give that a try.
Oct 15, 2014 at 5:44 PM
Edited Oct 15, 2014 at 6:00 PM
OK... I made these changes:
<dependentAssembly>
        <assemblyIdentity name="Microsoft.Practices.Unity" PublicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="2.0.414.0" newVersion="2.1.505.2"/>
      </dependentAssembly>
<dependentAssembly>
        <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" PublicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="2.0.414.0" newVersion="2.1.505.2"/>
</dependentAssembly>
Now the module isn't "visibly" breaking (no ugly error right on the page), but it's not working either.

Is it possible other related dlls need to be upgraded? Say "Microsoft.Practices.EnterpriceLibrary.Common", etc? If so is there a quick place to go grabs the correct matching versions? (the Microsoft site is a mess)

I am seeing this partial error in the other module that breaks:
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.CreateDefaultContainer(IConfigurationSource configurationSource)
   at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.SetCurrentContainerIfNotSet() in e:\Builds\EntLib\Latest\Source\Blocks\Common\Src\Configuration\EnterpriseLibraryContainer.cs:line 93
   at Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.InnerCreateDatabase(String name) in e:\Builds\EntLib\Latest\Source\Blocks\Data\Src\Data\DatabaseFactory.cs:line 76
   at SWBC.CorpSite.Dnn.Modules.BuyingProgram.BuyingProgramPublic_View.loadConfigData() in C:\CorporateSite\SWBC.CorpSite.Dnn.Modules.BuyingProgram\BuyingProgramPublic_View.ascx.cs:line 237
   at SWBC.CorpSite.Dnn.Modules.BuyingProgram.BuyingProgramPublic_View.Page_Load(Object sender, EventArgs e) in C:\CorporateSite\SWBC.CorpSite.Dnn.Modules.BuyingProgram\BuyingProgramPublic_View.ascx.cs:line 44
Thoughts?

Maybe just re-compiling 2sexy with the older dll at this point would be better? :-)

Thanks,
Dave
Coordinator
Oct 16, 2014 at 9:03 AM
Apparently the thing is trying to get a "Container" - that's a Unity thing. But apparently unity is actually running (so the new version must be working...).

My guess: the configuration for unity might have changed a bit - and maybe this fails. but I just don't know. I recommend n contacting the guys who created the "old" tool, it's probably trivial.
Oct 16, 2014 at 2:52 PM
Edited Oct 16, 2014 at 3:06 PM
I love to contact them, but they are ex-employees of the company I work for, and that code is simply gone. So I'm pretty much stuck.

Is there anyway to recompile 2sxc with the older version of unity? I'm definitely not the best candidate for doing that (I'm not afraid to admin it!). Any help would be GREATLY appreciated.

Thanks
Oct 16, 2014 at 4:43 PM
At this point I'm not opposed to begging if you can recompile 2sxc with the older Unity. As I said, I really want to use it with my sites, just stuck with this other old code. I know I won't be able to get support with it, but until I can do away with these other extensions, I'm OK with that just as long as I can use it. :-)
Coordinator
Oct 17, 2014 at 12:14 PM
@dsgreen: I guess we could try this, but it would take some time to do and test, and we couldn't do it for free - even if it turns out not to work. If you're interested, contact us at info at our 2sxc org