Documenting webapi with Swagger

If you’ve ever worked with webservices, chances are you’ve run into WSDL ( In the webapi world you don’t get so much out the box – this is where swagger can help expose test methods, documentation and a lot more.

For projects you can make use of a library: Install via nuget and you get a UI allowing a configurable interaction with all the webapi methods in your solution:

The swagger UI:
swagger ui

The test controller and methods:
webapi methods

All pretty simple stuff – how about if you want to secure things?
An example scenario might be you only want swagger accessible if you are visiting via http://localhost (or a loopback url).

It’s straight forwards if you implement a custom webapi DelegatingHandler.

This then needs wiring into the webapi request pipelines. In your WebApiConfig file (OTB in your solution in the folder: App_Start) add:

In the TestController example above we had several httpPost methods available – to enable this functionality you need to allow the routes to include the {action} url chunk.

Azure webapi’s are now compatible with swagger – see for more info.

Grunt and gulp tasks in visual studio 2015 – libsass error

One of the neat features baked into the new Visual Studio is the ability to run grunt and gulp tasks. This can be done on demand via the Task Runner Explorer or tied into build events.

Some simple steps for getting started with Grunt are:

All pretty cool, if it works! If you’ve got a version of node installed be aware that Visual Studio also ships with its own. It took me a while to track down so thought it worth sharing. If you receive errors when trying to run these tasks eg:

Then try swapping the options so that $(PATH) is higher priority than the MS Web tools option:



This was found with some help from:

No Sitecore logs, no Event log entries and no working site?

It’s not a nice place to be I’m sure you’ll agree!

Before we go on, I can’t guarantee one size will fix all!! This worked (well, fixed) our setup – it’s by no means the only way to solve the scary place of no working site.

In our setup we make use of the IIS URL Rewrite module. Under the hood this maps some xml within the web.config to the rules it applies. If for any reason you’ve goofed up this config, easily done with rogue config transforms or general typo’s, then you may have broken this IIS feature. The giveaway, when you double click the feature in IIS you receive an error message.

The reason for posting – this took me a while to track down the first time, now it’s my go-to verification if we don’t get any Sitecore logs or Event log entries.

The issue here isn’t really related to Sitecore, the lack of Sitecore logs is simply another symptom of the problem.

Moq – the basics

During a recent XP programming course we made use of the Moq’ing framework. I’d not used this before so tried to come up with some example moq basic tests. There are several tutorials on the internet which offer up the basics so do hunt around. Hopefully the following provides some simple examples for people to get started with.

The following code relies on the following assemblies:

The real crux of TDD is that you program your functionality to interfaces – here we have a simple interface and dto:

Note the importance of the virtual property in MyObject will be highlighted in the tests. In the following examples not all the tests pass – this is intentional! Failing tests are included to demonstrate specific features of Moq. Apologies for the long dump of test code – the idea is really to copy it into a test class and let NUnit do the work.

Here is the expected results when evaluated in NUnit:

Adding functionality to interfaces with extension methods

When building large scale applications a very useful design pattern to adopt is dependency injection. An example of this is programming to interfaces such that the implementation of each interface can be interchanged.

In this post I will demonstrate some examples of how you can go about adding functionality to interfaces with extension methods.

Consider the following example with some demo interfaces and classes:

This is all well and good – the user can write log entries with the following line:

So, how can we achieve:

The interface cannot contain any implementation. One solution would be to use abstract classes for the base class however that goes against the principal of programming to interfaces.

How about extension methods? Using the following examples we can add these shorthand methods to our ILog hiding some of the complexity / repeated code:

If you setup the extension methods in the same namespace as your interface, you will now have available:

Add ITemplate content to a controls markup

When building web controls, a common scenario is how to cascade control parameters to the control from the markup (or code-behind). Within Sitecore controls this is typically the Field you want to render.

This approach to programming controls works very well until the set of parameters becomes very long or the control doesnt need to know about each parameter. Consider embedding a flash movie, the number of parameters to code could be huge.

In the flash example, often the parameters aren’t needed by your c# code, instead they just to be rendered to the markup.

One useful tip is that you can get information from your code behind into the template markup eg

To build the control you need to add the following attribute:

And then the template you want to use:

The content of the template can be extracted as a string with the following:

Note, based on the chosen implementation, you may not need the content of the template as a string. Instead you could simply instantiate to the control’s child controls