Connecting Open Live Writer to Umbraco Channels For Authoring Content or Blog Posts

Thursday, April 6, 2017 by Nate Bross

Open Live Writer is a great, free, open source version of the late great Windows Live Writer, from the Windows Live Essentials package of yore. I’ve never been a prolific blogger, but having a nice slick thick client for formatting and image maintenance is always great. Using Umbraco and Open Live Writer works well, but it doesn’t have to be only for blogging! With Umbraco Channels you can direct content from Open Live Writer to various areas of your site.

I’ve set this up a dozen times, and every time I have to google around until I find the solution.

Umbraco Setup

Setup a channel for the user, in the Backoffice go to:

Users => Users => [Your-Account] => Content Channels (Tab)



I’ve called out the important areas.

Start Node in Content: should match the folder you setup in the website.

Start Node in Media Library: useful if you want to keep all the media for your posts grouped together

Document Type: This is the document type that will be created for each Post in Open Live Writer.

Description Field: the field on the document type in which the main content will go.


Open Live Writer Setup

Website =>[folder-if-setup]

User => Backoffice Username for this channel

Password => Self Explanitory

Blog Type => Metaweblog API

EndPoint => 

That’s the part I always forget.


What’s interesting here, is that if you want to manage multiple content sections from within Open Live Writer, you can create multiple Umbraco Backoffice users with one Channel per area in the site. Since Open Live Writer supports multiple accounts, you can link them all up and have a mostly seamless experience. Using different ‘accounts’ is a clunky way to manage multiple areas, but if you think of them as channels it makes some sense.

xUnit Tests in a VSTS Build Failing Upgrading to netcoreapp1.1 and Microsoft.NETCore.App 1.1.1 with project.json and preview 2.1 tooling.

Wednesday, April 5, 2017 by Nate Bross

When using netcoreapp1.0 I had been using the existing Visual Studio Test task from the Build Editor (v1.x) and simply overriding the ‘path to dlls’ with a ‘path to project.json` file as outlined here.

Upon upgrading the application and all tests to netcoreapp1.1 VSTS started failing builds with the following error:

Error: 'test-xunit' returned '-2147450749'.

Running these tests locally though Visual Studio, `dotnet test` and vstest.console.exe all worked just fine.

Scouring the internet, you’ll find plenty of sources suggesting that you add the nuget package ‘Microsoft.DotNet.InternalAbstractions’ to your test project. In my case, this did NOT solve the problem.

The only way I could get it working was to downgrade the test projects from

Microsoft.NETCore.App : { version: 1.1.1 }


Microsoft.NETCore.App: { version: 1.1.0 }

I suspect that the build agent doesn’t have v1.1.1; and that is why running locally the tests always work. All I know for sure is that running it locally everything worked fine, but it would blow up on a VSTS Build Agent.

Optimizing Front End Resources

Wednesday, December 9, 2015 by Nate Bross

Optimizing front-end resources can be lots of fun, if you’re using a good framework for it. For your standard ASP.NET web application WebGrease and the built-in Microsoft tools work pretty darn well. Things get a little bit interesting when you start working with things like LESS or SASS as compilers for these systems can start bundling things up and making minified versions. That’s fine and good, unitl you need or want managed caching. That’s where server side frameworks come into play.

Enter: ClientDependency Framework. Its what powers this site. Its a nice simple framework that makes sense. The code speaks for itself, and since it lives in the views it doesn’t get lost in some .cs file.

Firstly, its available as a nuget package. In order to get started, you want to simply punch in these commands:

PM> Install-Package ClientDependency
PM> Install-Package ClientDependency-Mvc

Then you can jump right into your view code:


This makes the view depend on these files, they are not rendered here, but when these views are used, the last call below knows which scripts to include:


ClientDependency Framework handles all the messyness of combining and minifiying these resources, adding query strings to the <script> and <link> tags so they are cached, but can be invaldiated in future updates. Using this framework properly, you should never have to tell a client, just do a “hard” (CTRL + F5) refresh.

 View More Posts