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.

Read More

How To Fix Sitecore Connector Version Issues After TDS Upgrade

Background

It is pretty obvious that if you are doing some form of Sitecore development, you are probably using Hedgehog's Team Development for Sitecore (TDS). It makes life so much easier when working on large projects with several team members.

The Upgrade Problem

I am running Visual Studio 2015, and ran into a peculiar problem after updating to the latest version of TDS. I had previously been running 5.1.0.17 and upgraded to version 5.1.0.20.

I was stuck in an endless loop where my connector was showing this error: "Warning: The version of the sitecore connector is from a different version of TDS." An addition, my output window was displaying this message: "Warning: Connector returned version 5.1.0.17. Looking for version 5.1.0.15."

 Warning: Connector returned version 5.1.0.17. Looking for version 5.1.0.15  
 Connection Test Start: 2015-11-05 09:13:54  
 Connection Test Pass: Content downloaded from http://hfedev/sitecore  
 Connection Test Pass: TDS connection test successful  
 Connection Test Message: Connector version local 5.1.0.15 and msbuild 5.1.0.15  
 Connection Test Pass: MSBuild version correct.  
 Connection Test Pass: Sitecore.Kernel.dll and Web.config found beneath G:\Inetpub\wwwroot\HFEDev\Website  
 Connection Test Pass: TDS service files are correctly installed.  
 Warning: Connector returned version 5.1.0.17. Looking for version 5.1.0.15.  
 Warning: Connector returned version 5.1.0.17. Looking for version 5.1.0.15.  
 Connection Test Failure: Failed to complete test.  
 Exception The given key was not present in the dictionary. (KeyNotFoundException):  
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)  
   at HedgehogDevelopment.SitecoreProject.VSIP.Utils.Support.CallServiceWrapper[T](TdsServiceSoapClient client, SitecoreProjectNode project, Func`2 clientCall)  
   at HedgehogDevelopment.SitecoreProject.VSIP.ProjectTests.AccessGuidTest.Execute()  
   at HedgehogDevelopment.SitecoreProject.VSIP.Dialogs.BuildTestDialog.RunTests()  
 Connection Test Finish: 2015-11-05 09:14:02  

This was pretty weird as I had just upgraded from version 5.1.0.17 to 5.1.0.20.

The Path To Solving The Problem

I started out by taking a bit of an invasive approach to fix the problem, as it had worked for me before after I ran into a similar issue. I navigated to my Sitecore instance, and deleted  the _DEV folder (that contains the TdsService.asmx) and then deleted the TDS assemblies from my bin folder. After this, I tried to install the connector again.

Unfortunately, this didn't help fix the issue, and I now had the following error:

I checked to make sure that my Access Guid in my various projects matched what was in the service's web.config, and they were in fact the same:

Getting Closer

After restarting Visual Studio, and trying my Sitecore Connector again, I started getting the same type of error message that I got initially, except now it was showing that it was looking for version 5.1.0.20 which was the version that should have been installed.

 Connection Test Start: 2015-11-05 09:43:44  
 Connection Test Pass: Content downloaded from http://hfedev/sitecore  
 Connection Test Pass: TDS connection test successful  
 Connection Test Message: Connector version local 5.1.0.20 and msbuild 5.1.0.20  
 Connection Test Pass: MSBuild version correct.  
 Connection Test Pass: Sitecore.Kernel.dll and Web.config found beneath G:\Inetpub\wwwroot\HFEDev\Website  
 Connection Test Pass: TDS service files are correctly installed.  
 Warning: Connector returned version 5.1.0.17. Looking for version 5.1.0.20.  
 Warning: Connector returned version 5.1.0.17. Looking for version 5.1.0.20.  
 Connection Test Failure: Failed to complete test.  
 Exception The given key was not present in the dictionary. (KeyNotFoundException):  
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)  
   at HedgehogDevelopment.SitecoreProject.VSIP.Utils.Support.CallServiceWrapper[T](TdsServiceSoapClient client, SitecoreProjectNode project, Func`2 clientCall)  
   at HedgehogDevelopment.SitecoreProject.VSIP.ProjectTests.AccessGuidTest.Execute()  
   at HedgehogDevelopment.SitecoreProject.VSIP.Dialogs.BuildTestDialog.RunTests()  
 Connection Test Finish: 2015-11-05 09:44:02  

The next thing I did was I add a new empty TDS project to my existing solution. Interestingly enough, the connector worked like a champ with no issues:

I then went ahead and tested the connection on the rest of my projects and they all worked too!

Yeah baby!

Problem solved? Well, not exactly.

The Final Solution

After successfully testing the connection on all of my existing TDS projects, I went ahead and deleted the empty TDS project. I am sure you can guess what happened next right? The other projects started failing to connect again!

So, what was different after I added the new TDS project? Mmmm. It had a different Access Guid than the other projects. That was weird though. How would the other projects connect then?

I went ahead and created another new, empty TDS project, configured it, did a test and made sure that everything passed. Then I copied the Access Guid from the new TDS project and replaced the Access Guids in all my projects with the new Guid. 

After doing this, I did a test on all the TDS projects in my solution, and every one of them worked like a champ.

Finally, I went ahead and I removed the empty TDS project. This time, after removing the empty project,  all my connections continued to work perfectly!

Read More

Official Fork of the Improved 301 Redirect Module

After chatting with Chris Adams about my recent contributions to the improved version of the 301 redirect module (Original version was created by Chris Castle, available on the Marketplace), and the launch of version 2.0, we decided that I would be taking over the maintenance of the module. So if you have any questions or run into issues, you can inbox me at menglish@arke.com or reach out to me on Twitter: @MartinREnglish.

The new repository url is: https://github.com/martinrayenglish/301RedirectModule

Some improvements you will see in version 2.0 include:

Ability to handle redirects for non-Sitecore hostnames

• New setting for pipe separated list of non-Sitecore hostnames that are bound in IIS that you want to allow redirects from. Eg. "mydomain.org|www.myotherdomain.org"
• New setting to redirect external host names where there is no match found, to a specific URL

Ability to redirect to relative destination paths using the redirect pattern. Eg:

• Requested URL: http://www.mydomain.org/nice/blog/2015/12/1
• Regex match for “^/nice/blog/?”
• Redirect to http://nice-blog.myotherdomain.com/ set
• Redirect will go to http://nice-blog.myotherdomain.com/nice/blog/2015/12/1

Geolocation Redirects using MaxMind

• Ability to use MaxMind’s GeoIP2 Database or GeoIP2 Precision Services to determine visitor location, and redirect to specific URLs if a location match based on ISO Country Code or Continent code is found.

Caching layer for Geolocation Redirects

• This was introduced to improve performance of Geolocation lookups

Hope that community benefits from the improvements!

Read More