If you have to use Ninject with Solr...

My first time having to configure Solr for Sitecore recently taught me a variety of new things. (I know – how have I managed to avoid it this long?) Most of the basics of the setup have been well documented elsewhere, so I won't repeat any of that. However setting up the site to use the Ninject DI container wasn't as smooth as the documentation suggested, so here are some notes on the issues I hit in case you find yourself stuck:

Background url copied!

I was looking at a site based on v8.1 update 3, which was using Lucene for search. It already had an instance of the Ninject DI container, since this is installed as part of the social features for Sitecore. While I understand Ninject may not be the fastest container in existence, I decided I preferred making use of that to adding another container to the solution. YMMV – but that's not the point of this post.

Hence I started looking at Sitecore's instructions for configuring Solr‘s IoC to use the existing Ninject code.

Process url copied!

On my first pass through Sitecore's docs, I'll admit I may not have been paying quite sufficient attention. But I made the changes to `Global.asax` that they specify for Ninject, and I copied all the files from the Solr Support Package which mentioned Ninject. Trying to browse my site, I got my first YSOD of the day:

Could not load file or assembly 'Ninject, Version=3.0.0.0, Culture=neutral, PublicKeyToken=c7192dc5380945e7' or one of its dependencies. The system cannot find the file specified.

So the first issue to address is that Sitecore's Solr support has been built against a different version of Ninject than the version they ship with their social code. But at least that's fairly easily fixed with a Assembly Binding redirect. Looking at the existing configuration, there was already some config for the location of the Ninject binary in place, so I amended it. In the /configuration/runtime/assemblybinding section of the site's web.config I added:

<dependentAssembly>
    <assemblyIdentity name="Ninject" publicKeyToken="c7192dc5380945e7" xmlns="urn:schemas-microsoft-com:asm.v1" />
    <codeBase version="3.2.0.0" href="bin\Social\Ninject.dll" xmlns="urn:schemas-microsoft-com:asm.v1" />
    <bindingRedirect oldVersion="0.0.0.0-3.2.0.0" newVersion="3.2.0.0" xmlns="urn:schemas-microsoft-com:asm.v1" />
</dependentAssembly>

					

With that saved, and the site refreshed I immediately hit a second YSOD:

Could not load file or assembly 'CommonServiceLocator.NinjectAdapter, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

At this point I scratched my head a bit, and went to re-read the instructions in more detail.

The "Select the correct support DLL files" section of the instructions says that for Ninject three DLLs are needed. The files Ninject.Integration.SolrNet.dll and Sitecore.ContentSearch.SolrProvider.NinjectIntegration.dll are in the Solr Support zip file for this version of Sitecore and I'd copied over already. But CommonServiceLocator.NinjectAdapter.dll was not there... I spent a certain amount of time wondering if I'd missed some obvious link to download the file – but it appears not.

So my first guess was "maybe it's on NuGet"? But this file doesn't appear to be present in any of the official NuGet packages for Ninject. There is an "unofficial" package for this DLL but that contains the wrong namespace for the code Sitecore wants to call, so that's no good. However the right files are present in the source for Ninject on Github. Looking at the official wiki for Ninject, that suggests you can get releases from their build server. However, that link did not work – clicking it went to https://teamcity.bbv.ch/viewLog.html?buildTypeId=bt7&buildId=lastPinned&tab=artifacts which then redirected automatically to an OAuth2 endpoint on the server http://dmzytr01:8080/ - which clearly isn't going to work for those of us on the public internet...

So, back to the drawing board. Instead, I cloned the source from Github to build my own version of the DLL. Given that the Ninject dll that ships with Sitecore is version 3.2.2.0, I took the source for 3.2.2 and compiled a release version of that. I finished the setup described in Sitecore's doc by copying all the files and updating the Global.asax and tried to load my site...

No luck – the same YSOD again – even though the DLL was now present.

Looking at the DLL I'd deployed I had a quick facepalm – of course the Solr support has been built against the older version of Ninject, so I've just built the wrong version of the DLL. So after some scrabbling about in the release history for Ninject on GitHub I re-downloaded the source and got v3.0.0 to compile the CommonServiceLocator code.

Digging into this, I spotted two further issues with this that needed correcting: First, the solution was configured to sign the assembly for a release build. So I undid that bit of configuration in Visual Studio so the output would match Sitecore's needs. But more oddly, the source for the V3.0.0 DLL from GitHub had a version number of V2.3.something. I decided to bet that this was a "forgot to check in the assembly version change" issue with the source code, and modified that myself before rebuilding.

And with that version of the DLL copied over, the site finally loaded and let me build indexes...

↑ Back to top