March 22, 2013
This is actually not Sitecore specific; however, I encountered the following situation while I was installing Sitecore 7. I received a Lucene.Net.Util.Version error saying that it could not be loaded, as there was a type mismatch.
To provide some background, before version Lucene.Net 3.0, the Version type was a class. Now the version type is an enumeration. Since Sitecore 7 uses the latest and greatest version of Lucene, I knew it had something to do with version type. So, I checked my local bin folder to see if I had an older version. Nope. I then checked the GAC to see if there was anything there. Of course not. Maybe the ASP.NET temp folder? No cigar. So where was it? Of course at this point, I really didn't know that it was loading a different version and resulting to that error. So, here were my steps debugging this:
- I performed the checklist described above trying to find the assembly, but with no luck.
- I then tried to see if I only need to set to 18.104.22.168 because the one that came with SC7 shows newVersion=22.214.171.124 but that still didn't work.
- I tried to see if removing the bindingRedirect element would help, but it didn't make a difference.
- At this point, I decided to figure out what was IIS loading? To do that, I used a nifty tool called Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx). It tells me in real-time what registry and files are being accessed by any process.
- I ran Process Monitor and filtered to process w3wp.exe for the IIS.
- I hit my Sitecore website (default install of SC7) and looked at the results on Process Monitor.
- I then searched for "Lucene" and saw several results.
- I didn't really see anything out the ordinary as it showed that IIS was looking at the temp folder, etc. Sidenote: I did notice that when I was looking at the ASP.NET Temp folder, I didn't see a cached version of the Lucene.Net.dll assembly, but I did with the other Lucene.NET assemblies.
- Then I saw one that pointed to my local .NET Reflector (C:\ProgramData\Red Gate\.NET Reflector\DevPath). So, I went there and found the culprit file Lucene.Net.dll. It was an older version.
- I removed that and hit my site again and it worked!
So, what's the deal? Well, I found out that Red Gate uses and sets the DEVPATH. Of course, you can set DEVPATH yourself or with another program. It is meant for debugging purposes, particularly for shared assemblies. So, .NET (specifically .NET Fusion) uses the DEVPATH (provided developmentMode is set to true in the machine.config -- normally it's not) to determine where to load the assembly from. A call to Assembly.Load (et al) uses DEVPATH.
Here is where it gets funny (sort of)? This type mismatch error would not have happened if I was using .NET 4.0 for my site because there was a bug in which .NET wasn't using the DEVPATH. It does happen if you're running a Windows app. Since SC7 is now in .NET 4.5, Microsoft fixed the issue. So, when IIS runs the site in development mode, it actually now uses DEVPATH and I get the error.
Anyway, all I had to do after all of this was remove the assembly from my DEVPATH directory. Of course I could switch the developmentMode to false but it's my local development machine.
Well, that was my adventure in installing Sitecore 7. I'm about to go in and see what I can play with. I'm excited about all the features. Although this post is not specific to Sitecore, I do want to mention a couple of points that you may not have noticed that are specific to Sitecore 7:
- It uses .NET 4.5 (Sitecore now takes advantage the improved garbage collection plus other 4.5 features such as arrays over 2GB, better compression sizes, etc.).
- It uses the latest Lucene.NET 126.96.36.199 (which means if you coded against it, you may need to see if your code works as there are some API updates just like the Version type from a class to an enumeration).
Sitecore 7 is on the horizon and it brings Sitecore to a whole new level of enterprise-ready. Although the release is not just about performance, scalability and massive data, it does open up a whole world of bigger applications. The idea of it being a platform instead of primarily a CMS is definitely a direction that Sitecore likes. With this release, I am seeing DMS, ECM, SIP, Foundry, etc., taking advantage of all these in various ways. Now, it's time for me to explore further and see what else is in store for me.
comments powered by