Getting on the 8.1 Train

Background

I recently got my development team on one of our projects updated from 8.0 Update-5 to 8.1. It was a pretty seamless process, obviously always easier when you are in development as opposed to performing an upgrade on a production site.

Content 

We use Hedgehog's Team Development for Sitecore (TDS), and so all of our content was serialized and available in source control.

Solr 

We are using Solr on the project, and after following these steps, everything was working like a champ:

• Added the required assemblies from the 8.1 Solr Support package from here: http://bit.ly/1NlFu4W. 
• Updated our Global.asax to include the Castle / Solr Support. 
• Ran Patrick Perrone's Solr switching script http://bit.ly/1YkXPUS. 
• Added the new sitecore_marketing_marketingdefinitions index. 
• Rebuilt all indexes to verify Solr and Sitecore were playing nice.   

MVC Areas 

We have been using a custom implementation to address the unsupported areas issue for quite some time. The switch over to Sitecore controller renderings with support for areas was straightforward. I just removed the pipeline processor in our custom implementation, changed the template type from our custom controller rendering to the new OOTB controller rendering with the area field populated and it worked perfectly.

NuGet and Such 

As most of us are aware, 8.1 supports the latest and greatest versions of MVC and Web Forms. So I had to make sure that my various modules and solution's NuGet Packages were up-to-date with version 5.2.3 of MVC, Razor 3.2.3 and WebPages 3.2.3. One thing I noticed that was interesting was the version of Microsoft.AspNet.Cors was still 5.1.2.

Glass Mapper 

We use Glass Mapper in our implementations, and I had no issues after installing the latest version (4.0.5.54 at the time of writing this) from our friend Michael Edwards: http://bit.ly/1lCnwSW

Castle Windsor 

Castle is our DI framework of choice. For some reason, when I got 8.1 up and running, I started getting the following error when running my IOC controllers:

Looks like you forgot to register the http module Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule Add '<add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.MicroKernel" />' to the section on your web.config

 Adding the following entries to the web.config fixed the issue:

 <system.webServer>  
  <modules>  
   <add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.Windsor" />  
  <handlers>  
   <add name="PerRequestLifestyle" verb="*" path="*.castle" preCondition="managedHandler" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.Microkernel"/>  

I am interested to understand why this has worked via Microsoft.Web.Infrastructure dynamically registering Castle before instead of me having to explicit register Castle in the web.config.

sc_site 

This parameter has always been around, but now, it is added to the url when you are in Preview or Experience Editor mode within your site(s). The problem I am having is that for some reason, it is always set to "website". We know that "website" is special in Sitecore and necessary for features to work correctly in a multi-site setup. But why is sc_site always "website"? I validated all my site configurations. Looks to be an annoying bug.

UPDATE: Thanks to Kamruz for pointing out the new <setting name="Preview.ResolveSite" value="false"/> config value in Sitecore.config. Changing the value to "true" fixed the issue.