I’ve been working on a project the last couple of weeks, integrating an E-commerce system with an Umbraco website.
The E-commerce platform uses Lucene.Net 3.0.3 to manage its catalog. Umbraco uses Lucene.Net 220.127.116.11 to power its search engine. These two versions of Lucene.Net are different enough for both projects to not want to share.
The phrase “DLL hell” keeps going round in my head – wonder why…
There’s a couple of things I’ve had to do in order to get these two systems to “play nice” with each other – the first is to use Assembly Dependencies in the web.config to reference one version of the Lucene.Net DLL, whilst the other version of the DLL is referenced within the project as usual.
As my main project contains Umbraco “stuff” that needs to build (and fails to build if it can’t find the correct version of Lucene.Net) I reference the 18.104.22.168 version in my project:
For the 3.0.3 version of the DLL, I add this to the assemblyBinding section of my web.config file:
This dependentAssembly configuration essentially means that a component which requires a version of Lucene.Net older than version 3.0 will use version 22.214.171.124, grabbing it from the BIN directory of the solution. Components that require anything after version 3.0 will use version 3.0.3 and grab this DLL from the location set in the codeBase section.
TIP: to find out the publicKeyToken for any DLL, you can navigate to the folder that contains that DLL using the Visual Studio Native Tools Command Prompt, and run this command:
sn -T Lucene.Net.dll
So once I’ve done all of this, Umbraco and the E-commerce platform to be friends, and co-exist in the same solution.
There is one other issue however…
If you publish your code to a server (production, staging etc) using a Visual Studio publishing profile, the Visual Studio publish process only includes files that are part of the solution (and also only ones that are actually being used as part of the solution!). So in this example your v126.96.36.199 DLL would be copied up ok because it’s referenced in the project file. However the v3.0.3 DLL hasn’t been included in the project so it won’t be included in the publish step, and your website will fail miserably once it’s been deployed to your server. You will probably cry just a little bit.
To sort this, you need to include the v3.0.3 DLL in your Visual Studio project. Make sure the file is in the same folder as your project file (I usually stick DLLs like this in their own folder within the solution), click “Show all files” in your Solution Explorer, and then right click on the DLL and click “Include In Project”:
Now when you publish your site, the Visual Studio publish process will also copy up your v3.0.3 DLL and maybe (just maybe…) things will start to work!
One final gotcha to be aware of.
If your referenced DLL version is higher than the version you included in the project (i.e. the opposite of this scenario) then by default Visual Studio will try to use the oldest version instead of the one you actually referenced!
To stop this happening, you need to view the properties of your referenced DLL and change the “Specific Version” property to TRUE: