TODO Comments have no place in Master

Don’t get me wrong, as a professional C# developer I love using TODO markers in my code. They document minor details that I need to revisit and allow me as a coder to keep moving with the aim of getting an overall structure in place. I do this in feature branches and I often do a git rebase -i to tidy up all of my local commits into something more meaningful to merge back into the develop or master branch.

As you are reading this I hope that you will agree with the next few points that I make about source code best practices. So here are my views on what I believe to be a sensible perspective on how you treat releasable code.

Advertisement

Glimpse for Sitecore

Welcome to a new era of server side diagnostics with Sitecore. In the past we had the following tools to help us identify performance issues with our Sitecore installations:

• Sitecore Log Analyzer (SCLA)
• ASP.NET Trace
• Sitecore Debugger
• Sitecore Admin pages
• Sitecore Rocks

These tools could be used in circumstances where it is not possible to attach a debugger or application profiler like the ANTS Performance Profiler to a running web application. No there it’s time to add a new tool to this list, that tool is Glimpse.

Fixing up Sitecore.Nuget connections

This post aims to document an issue and workaround for something that I spotted when working with Sitecore.NuGet to install Sitecore enabled NuGet packages.

For the uninitiated the following extract explains the idea behind these packages.

Sitecore.NuGet allows NuGet packages to be installed in a Sitecore solution, including Sitecore items.

A Sitecore NuGet package that contains items requires the Sitecore Rocks Hard Rock web service installed on server and that the Visual Project has been connected to the Sitecore installation.

The open source Sitecore.Mvc.Contrib project uses Sitecore.NuGet to package up and install Sitecore content items. In order for these packages to install the Visual Studio project has to be connected to a Sitecore site. In itself that is not a problem, simply right click on the project file in the Visual Studio Solution Explorer, select Sitecore -> Connect to Sitecore Explorer Connection… on the context dialog and connect to a Sitecore website. This will add a connection to the Sitecore Explorer as shown below.

After configuring the project you should be able to install a Sitecore.NuGet package like any other.

PM> install-package sitecore.mvc.contrib

The regular files within the package get installed as expected and then a nasty surprise pops into the package manager console output.

Successfully added 'Sitecore.Mvc.Contrib 1.0.1' to Website.
 install-items : A connection to "sc66contrib (sitecore\admin)" was not found.
 At C:\Websites\sc66contrib\packages\Sitecore.Mvc.Contrib.1.0.1\tools\install.ps1:19 char:3
 + install-items -toolspath $toolsPath -project $project -dte $dte;
 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : NotSpecified: (:) [Install-Items], InvalidOperationException
 + FullyQualifiedErrorId : System.InvalidOperationException,Sitecore.NuGet.Installing.InstallItems

I’m obviously not alone in suffering from this issue:

@KevinObee @TheRocksGuy this. If you’re using local IIS sites in latest rocks it’s busted anyway.

— Kam (@kamsar) August 2, 2013

Using Cassette with Sitecore MVC

Cassette is a fantastic bundling and minification solution for those developing in ASP.NET. It automatically sorts, concatenates, minifies, caches and versions all your JavaScript, CoffeeScript, CSS, LESS, Sass and HTML templates. By doing this you end up with web pages that issue fewer HTTP requests and you reduce the size of each of those requests.

I recently ran into an unexpected issue when using Cassette with a Sitecore 6.6 MVC implementation that took long enough to get to the bottom of, that I thought it worth documenting. After installing the Cassette nuget package and make the few changes necessary to configure my stylesheet and script bundles I was very happy with the results. All of my local CSS and JavaScript files had been minified and combined and were now being pulled down from the server with just two HTTP requests. Job done and in no time at all, or so I thought.

Deep investigation (Photo credit: Stéfan)

All was fine until I fired up the Sitecore Page Editor to work on some of the site content. What greeted me after I logged in was quote literally an empty page. The Chrome Dev Tools confirmed that the page requested had indeed returned a zero byte response. I faired no better when I tried to preview the page in the Sitecore Content Editor, I just got the same story, an empty page. The odd thing was that when I hooked up the Visual Studio debugger I could see that all of my MVC layouts, controllers and renderings were executing just as I expected. When this sort of thing happens I usually fall back to chopping out anything that could be interfering with the response, in this case pipeline handlers and finally modules. Eventually the culprit revealed itself, the CassetteHttpModule was responsible for my empty responses.

Hiding XDT Transforms from Sitecore

Sitecore ships with a very useful web.config patching feature that allows everything within the element in the configuration file to be modified and extended. It is a best practice recommendation not to modify the web.config file directly but instead use customised configuration files located within the App_Config\Include folder to overlay the modifications that your solution requires.

Rather that regurgitate information on how to use the web.config patching mechanism I’ll suggest instead that you start with John West’s post All About web.config Include Files with the Sitecore ASP.NET CMS for a definitive way into this subject.

web.config transform files

Developers working with ASP.NET web applications outside of the Sitecore ecosystem are likely to be performing their web.config transformations using Microsoft’s XDT transform syntax. The popularity of the XDT engine is such that it has recently be issued as a NuGet package so that it can be shipped with third-party products. Whilst on the subject of XDT transforms it would be worth pointing out the Slow Cheetah Visual Studio extension for those new to the area. This package enables you to transform your web.config or any other XML file based on the build configuration and preview the outcome – simply invaluable.

Setting Up a Local NuGet Gallery

For a while now I’ve been wanting to hook up our continuous integration process with a local NuGet gallery. The basic idea is for the build process to produce NuGet packages containing components that are used across a number of internal developments. These packaged up components would then be published to a local NuGet gallery where the packages could be located by internal developers and pulled down into projects in Visual Studio that have a dependency on those components. Jetbrains announcement of native support for NuGet within their TeamCity application made this integration even more attractive.

At the time of writing the NuGet documentation on setting up a local gallery server is a little out of date, referring to an older version of the gallery. What follows is a simple set of instructions on getting a local gallery setup.

ReSharper friendly Visual Studio colour scheme

Looking for a dark visual studio style that’s not high contrast, easy on the eye for all day use and best of all ReSharper friendly then take a peek at Selenitic created by Tim G. Thomas.

 

This is just one of many Visual Studio styles available for download at http://studiostyl.es/ a great community site for creating and sharing Visual Studio colour schemes.