How to Debug Sitecore Kernel in Visual Studio using Reflector Pro or dotPeek

A post from Georgi Bilyukov a couple of months ago about Debugging Sitecore Using DotPeek informed me of a new feature in the latest version of JetBrains dotPeek that allows it to function as a symbol as a symbol server. If you haven’t read the post then I suggest you have a quick read.

So this sounded great – a way to debug Sitecore code, see where those calls end up and what is going on in the internals.

I’ve been using dotPeek for a while now, and before that .NET Reflector. These tools have been invaluable in getting a peek at the Sitecore code, and has become an everyday tool alongside Visual Studio and Resharper. My usual way of trying to debugging something Sitecore related is:

  • trial and error
  • copying the code for an existing pipeline and adding it before the default Sitecore one
  • override Sitecore controls, changing the codebeside to point to my own Class (which is also a copy of the Sitecore one)
  • grepWin the /sitecore folder
  • use dotPeek to generate a Visual Studio project and then grepWin the files to try and find something related as a starting point

Read More

Domain Sharding Media Requests in Sitecore

There have been a number posts about using Sitecore with a CDN provider and there is even a Sitecore CDN Connector module available Marketplace. Although the benefits of using a CDN provider are fairly well stated, such as reducing load on your server and allowing distributed datacentres, Sitecore itself does a pretty good job with its Media Library and for the vast majority of projects using a CDN may be overkill. Bedsides, there have been various projects I’ve worked on where they did not want the additional expense for little benefit or were unable to use a CDN to due to company policy or project requirements/specifications.

A project I was recently working on was utilising Edge Caching services from Akamai. If you’ve never used this type of service before, you need to re-route requests to your site to Akamai (by changing the DNS entry to point there). You can then configure Akamai as to which type of content should be served from cache and which needs to be forwarded on to your own server. There is nothing else for you to change, i.e. you do not need to provide a different domain prefix for your media items. This was an existing setup to the project from a previous vendor and seemed to work pretty well to meet the clients needs. One of the benefits we lose from not having a different domain name is the ability to domain shard.

Read More