Sean Holmesby

.NET and Sitecore Developer

By

Powerful ways you can save on Sitecore development time

Working on Sitecore? How much time are you actually wasting, instead of getting work done?
Maybe you’re a Slack-er.
Maybe you just think, ‘that’s how it is’ and you do things the hard, time-consuming way.
Or maybe you actually want something better…..

Anyone that knows me in the Sitecore community, knows my love for the tooling and processes of Sitecore development. Working at Hedgehog, it’s something we are constantly analyzing from our own projects, and something we are always trying to improve on. We aim to keep development costs down on projects by not cutting features, but by working better. This leads to happier clients, who get more bang for their buck when hiring a Sitecore development team.

So how do we do it?

Well, at Hedgehog, we not only do client work producing websites, but we also dedicate people to work on tools and modules that help improve things. Most of the time, these tools are born out of the frustrations that we’ve found with the paradigm, but also from the general murmurs from the community. Having hands-on experience with the problematic stuff in Sitecore development, we’re in a position to try and find ways to improve it. Sometimes this leads to shared source modules that we create, sometimes it’s examples of projects for people to see, and sometimes, with enough demand, it can result in full-scale, commercial products with 24/7 support and dedicated development teams.

TL;DR

  1. Use all the productivity features of TDS Classic
  2. Use Sitecore’s own tooling
  3. Use what others before you have already created
  4. Don’t wait for Sitecore’s lengthy app pool reload….use ZeroDeploy instead!
    Sitecore is Loading

Read More

By

True Delta Deploys with TDS Classic

TDS (now TDS Classic) 5.5 introduced a feature called ‘Delta Deploy’ where the deployment of your project, either in development (using the Sitecore Connector) or in update packages, had the ability to ‘skip’ items assuming that they’ve already been deployed.

By default, we needed to build this feature in a way that was agnostic of source control provider (Git, TFS, SVN), and agnostic of source control strategy (main-line dev, Git Flow, Github Flow etc)…but extensible, so that teams could develop their own logic for their own project.
Read More

By

Speed up TDS Code Generation time

TDS 4.0 introduced Code Generation as one of it’s features, and I’ve been using it on projects ever since. The fact that you have classes generated based on your Sitecore templates, means the time spent to hand roll these models is eliminated.

When setting up a TDS project with Code Generation, there are actually multiple ways this can be achieved. If you’re using Glass Mapper, you can follow the setup here. If you’re using Fortis, you can follow the setup here. Or if you are doing anything else, TDS allows for that flexibility as well.

One thing I do differently from most of these instructional posts is I set the Base Project Transform File in a different way.

When setting up Code Gen on a project, most people set the Base Project Transform File setting on the project properties page.

01-project-properties-page
This setting means that all of your items are subject to the processing of the .tt file.
Now, typically in that file, for instance in GlassItem.tt, there is a check to see if the item is a template, and if not, skip over it…..which is what’s required in most cases because you might typically only generate code for templates.
However there is still the little overhead of running the TT file on the item, and doing the check.

What I do instead is I keep the Base Transform File setting blank, and instead navigate to the root folder of the items I want to generate code for.
In the case of the LaunchSitecoreTDS project, this is the /sitecore/templates/Launch Sitecore item.
Then I open the properties on that item, and set the Code Generation Template to the TT file.

02-item-properties

Note: I also typically set the Namespace property here as well, also leaving it blank on the project properties page.

What this means that code generation processing is ONLY run on items below this folder, and not on all other items in my TDS project. This is perfect in the case where I’m only generating code based off my templates, and nothing else. No time is wasted on the content, layouts, media library or system items.
Using this setup, I manage to save a little overhead processing time when performing Code Generation, meaning I can get back to my code a little quicker.

 

By

TDS Post Deploy Step – Rebuild Content Search Indexes Script

This post shows how I created a custom TDS Post Deploy Step to rebuild the Content Search Indexes after my deployment in the Launch Sitecore TDS solution.

Hedgehog are currently asking for community contributions to the Post Deploy Step repository, so we can all benefit from each other’s work.

Got an idea for a Post Deploy Step? Let us know.
Getting started is super easy.

My Custom Post Deploy Step:
Rebuild Content Search Indexes

Problem: As a developer, you may have added new fields to a Sitecore data template, or extended Sitecore with a custom index field. TDS makes it easy to get your changes deployed to other environments, however, you can’t begin querying these fields until a full index rebuild is performed. Deploying new code without an index rebuild can result in search listings coming up empty, or worse, broken pages.
Read More

By

TDS Post Deploy Step – Rebuild Link Database Script

This post shows how I created a custom TDS Post Deploy Step to rebuild the Link Database after my deployment in the Launch Sitecore TDS solution.

Hedgehog are currently asking for community contributions to the Post Deploy Step repository, so we can all benefit from each other’s work.

Got an idea for a Post Deploy Step? Let us know.
Getting started is super easy.

My Custom Post Deploy Step:
RebuildLinkDatabase

Problem: When links are made between Sitecore items (for example, through the use of internal links, and reference fields), Sitecore will store those relationships in the Links Database. The Links Database provides quick access to these bidirectional relationships between items, allowing Sitecore to quickly retrieve related items. It’s generally a good idea to rebuild the links database from time to time, especially when working with reference fields or developing features that rely upon it directly.
Read More

By

Allow for Long-Running TDS Post Deploy Steps

This post describes how to increase the TDS deployment timeout setting so long-running Post Deploy Steps can complete their execution.

Team Development for Sitecore has many points of extension. You can implement custom code generation, custom MSBuild steps, and even custom project validators. These extensibility points make TDS capable of doing just about anything you want it to do in your build process.
To make things even easier, TDS 5.5 introduced Post Deploy Steps, and, as with many other TDS features, you can extend the Post Deploy Steps to run your own custom code.
Hedgehog are currently looking for developers to think up some custom Post Deploy Steps so they can be shared with the rest of the community.

Creating a Post Deploy Step is easy. Charlie Turano shows how a basic step can be created on the Hedgehog blog.
Read More

By

TDS AutoSync – one way is not the only way

This blog post was inspired by a comment on the TDS v5.5 Feature Spotlight Video for AutoSync.
The question was this:-

“Does it sync the other way around also? When you retrieve items from your source control and need to push them to Sitecore?”

The simple answer to that is no. AutoSync in it’s purest form only works one way. It will read changes from Sitecore into your TDS project, but will not take .item file modifications and auto update Sitecore with the changes.

We can make it happen though….. but first, the question has deeper connotations that I want to discuss.
Read More

By

Real-Time Auto-Reload Logging with Sitecore’s Rolling File Appender

Just found this…you may already know about it, but if not, hopefully it helps you with Sitecore development.

Sometimes you want to tail the log files from Sitecore, and see what’s happening in real-time on your Sitecore site.
But then you do a build or make a config change, logging stops in that file and a new log file is created. You then need to open that new file in the tailing program.

I’ve seen SIM‘s DynamicLogViewer reload the file automatically…. and also Nick Hills’ version of logging using DebugView, but I like Baretail (it has highlighting for easy recognition).

Anyway, I just found you can easily change Sitecore to always log to the one file.

Read More

By

TDS: The Evolution of Auto-Sync

Team Development for Sitecore (TDS) version 5.5 has now been officially released to the public I’ve had a play with the impressive list of new additions, and loved the further improvements to my Sitecore development efficiency. Features like the new Delta Deploy feature, and the Auto Deployment of Content Files have me doing Sitecore development quicker than ever.

One big new addition available in TDS v5.5 is the AutoSync feature… Another efficiency helper, where Sitecore changes get synced back to the TDS project automatically.
It has been described as a ‘new’ feature…. But is it?

Really, Auto-Sync has existed in TDS for a while, it’s just taken on a new form in v5.5.
Let me explain what I mean by this.

Read More

By

Safe Dependency Injection for MVC and WebApi within Sitecore

This post describes how we’ve considered approaching dependency injection with Sitecore at Hedgehog Development.
Many people have posted about dependency injection in Sitecore before, and each has had their own twist.

We’ve noticed that sometimes Sitecore controllers are failing to be resolved when there is a custom Dependency Resolver added.
The problem, as described in Mickey’s first post, is that MVC only allows for one DependencyResolver. So the moment you set your own Dependency Resolver, whatever was set there before (like whatever Sitecore set as the Dependency Resolver) will no longer work.
Because of this, Sitecore’s registered types will no longer get resolved, and you might see the following errors in the logs when you try to access one of the out-of-the-box Sitecore applications.

Exception: Sitecore.Mvc.Diagnostics.ControllerCreationException
Message: Could not create controller: 'Settings'.
The current route url is: 'api/sitecore/{controller}/{action}'. 
Source: Sitecore.Mvc
   at Sitecore.Mvc.Controllers.SitecoreControllerFactory.CreateController(RequestContext requestContext, String controllerName)

Message: No component for supporting the service Sitecore.Controllers.SettingsController was found

I spoke to Charlie Turano about this, and our solution was to create a ChainedMvcResolver, which will set a ‘Fallback Resolver’ to whatever the resolver was before we came along and set ours.
Read More