tl;dr: If you want logging to work with Helios, you need to add some things to your web.config. Snippet at the bottom of this article.

For a project at work, I’m using Helios to host a small ASP.NET Web API on Azure Web Sites. If that sentence doesn’t make sense, you might need to do some extra reading first:

• What is Helios?

• What are Azure Web Sites?

This setup works really well for us. Using OWIN with Web API hosted on IIS via Helios means we have a small amount of code to get the API running. Not only is the code small, it’s succinct and clear, because we don’t rely on large frameworks with side-effects and magic conventions.

Azure Web Sites provides easy to use logging. Application logging via the System.Diagnostics.Trace type is added automatically to Azure Tables and Blob Storage, and it’s then available via the Kudu Log Streaming Service. This doesn’t work for Helios out of the box. I did some debugging, and got as far as I needed to fix the bug without fully understanding the issue, as I couldn’t find the relevant code in Kudu. If anyone knows exactly why this doesn’t work out of the box, I’d love to know.

When you publish your ASP.NET project to Azure Web Sites, it automatically adds three new TraceListeners to your app: AzureDriveTraceListener, AzureTableTraceListener and AzureBlobTraceListener. These TraceListener types all exist in the Microsoft.WindowsAzure.WebSites.Diagnostics.dll assembly. I can’t find any reference to the assembly online, so it must not be in the open-sourced part of Azure Web Sites. You can download it from your Azure Web Site using the sample project I have in GitHub.

Azure Web Sites doesn’t seem to have full support for Helios hosted apps yet, so won’t do the automatic injection of the listeners. This is easy to fix by including the following in your web.config

1
2
3
4
5
6
7
8

<system.diagnostics>
    <trace>
      <listeners>
        <add name="AzureDriveTraceListener" type="Microsoft.WindowsAzure.WebSites.Diagnostics.AzureDriveTraceListener, Microsoft.WindowsAzure.WebSites.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        <add name="AzureTableTraceListener" type="Microsoft.WindowsAzure.WebSites.Diagnostics.AzureTableTraceListener, Microsoft.WindowsAzure.WebSites.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      </listeners>
    </trace>
</system.diagnostics>

Now you will have full application logging support in Azure Web Sites as if you were using a ‘real’ ASP.NET project. Hopefully this will help you avoid the three hours of debugging I did today.

Here is a video from some of the team that built SQL Scripts describing how it works.

Working at Red Gate has many perks— obligatory we’re hiring plug— but my favourite is Down Tools Week, when everyone stops working on their normal stuff for a week and follows their curiosity. It’s a good chance to scratch a few itches: everything from fixing some bug that never gets prioritized to building a remote-controlled robot that crowdsources its movements over the internet.

In the last Down Tools Week, I worked with a group of developers, designers and product managers to build a Management Studio extension that makes it easy to consume and share useful SQL snippets. It’s called SQL Scripts, and it’s backed by a repository of scripts on SQLServerCentral which already has thousands of scripts to help SQL developers and DBAs.

Apart from building a useful tool— feedback has been very positive so far, and people seem to be getting value from it —we also wanted to test technologies and methods relatively new to Red Gate before we added them to our established commercial products. We used lots of new technologies including CEF, OWIN and AngularJS to build a desktop product completely using web technologies, but still keep the tight Microsoft shell integration that users expect from us.

Looking at what we managed to build in one week, we’re pretty happy. The code is well designed considering the time constraint, and shows off some great techniques, like using CEF and Red Gate’s SSMS Integration Framework. We also had the luxury of building on great open-source projects like JSON.NET, log4net, AngularJS, Ninject, and a hundred other NuGet and npm modules, so it’s pretty polished.

We thought SQL Scripts might prove a useful example for anyone who wants to build a Management Studio extension or even a “normal” desktop app using web technologies. I’m delighted to say we’re open-sourcing the entire codebase on GitHub under the Apache licence. Hopefully, some of the code and techniques that we used will be useful in your own software. As always, pull requests are welcome. :)

My day job involves a lot of integration with Microsoft IDEs, mostly SQL Server Management Studio and the various flavours of Visual Studio.

Visual Studio 2013 has now been released so I can begin to explore some of the new features from an extensibility point of view.

One of the more interesting additions is the concept of user notifications, which is a central location where Visual Studio can show you notifications around updates or anything else that might be relevant to you.

This feature isn’t open for extensibility, but with the aid of .NET Reflector I was able to check out how this feature behaves.

The main functionality is accessed via a new type that has been introduced:

1
2
3
4
5
6
7

public interface IVsUserNotificationsManager
{
    IVsUserNotification AddUserNotification(Guid Provider, string Identifier, string Title, string Description, uint Severity, object Context, DateTime Expiration, bool isTransient);
    bool RemoveUserNotification(IVsUserNotification notification);
    void PromoteUserNotification(IVsUserNotification notification, uint Severity);
    IVsEnumUserNotifications GetUserNotifications(Guid Provider, uint filter, string Identifier);
}

To investigate how to use this new interface, I created a sample that fetches pictures from Reddit and adds them to the notification panel. You can find the source for this package on GitHub. It is easy to follow and the Visual Studio team have done a good job of creating simple interfaces. Looking forward to when this gets opened up for extensibility.

This is pure speculation, but I suspect the reason that Microsoft haven’t officially opened this up as an extensibility point is that notifications can be tiresome for a user and getting the experience just right so that they provide valuable information without being too spammy is a difficult balance. Please don’t use this feature in any extensions you write, I just hacked this sample together to show how it worked.

This is part 3 in my series about building desktop software using web technologies and the Chromium Embedded Framework (CEF). In this post I will explore the code patterns that I have used when building desktop apps using CEF. I have created a sample project that shows this pattern in action which you can grab from GitHub.

What is MVVM?

A common pattern in building desktop software when using WPF is Model-View-ViewModel (MVVM) where you separate the view layer from the code that drives the behavior of that view. You then use data binding to tie the view and view model together. You can read the nitty-gritty on the pattern on Wikipedia

MVVM and Chromium Embedded

Using CEF in your desktop software forces you to decouple your view from the core business logic of your software. The diagram shows how I have written my CEF apps so far:

View: The view in a CEF app is the DOM, the same as any web page. In the first apps that we built using CEF, we developed using HTML directly, but now we have switched to using Jade as a templating language to build the UI, but you can use the same approach that you normally use to building HTML.

View Model: The view models are written in JavaScript. We use Knockout.js to provide two way data-binding so that when something in our view model changes, the UI is updated and vice versa.

Model: We write the core of our apps in C# and bind objects that expose services on this model into the CEF frame at runtime. The view models can then call these services to interact with our model. My current product is a Visual Studio plugin, and some of the services we expose to our UI in that product allow our view to interact with the IDE and do things like start builds, open dialogs etc.

Advantages of the MVVM Pattern

The decoupling of the View and View Models from the Model mean that you can develop your UI in total isolation of your actual product. We achieve this by mocking out our model and services when we are running in a browser.

if (typeof ServiceProvidedWhenHostedInCef === 'undefined') {
    ServiceProvidedWhenHostedInCef = {
         SomeServiceFunc = function () {
         }
     }
}

Design Time Data: Having your view models delegate to the model through service objects means that it is easy to replace them during development. The mocks can then populate your view with mock data that is easy to change as it is changing JSON so there is no compile cycle to go through.

Tooling: There are hundreds of editors to help you create HTML. You can use Visual Studio if you like to use an IDE, or simply use Sublime if you find you are more productive in something lighter. The feedback loop in your development becomes a tight cycle as you can use Chrome Dev Tools to do live editing. Being able to, at runtime and interactively, change the styles and position of your UI elements is such a time saver. No more recompiling the app just to see if the button looks better 4 pixels to the right.

More Involved Designers: This one might be more relevant to teams at my company than generallybut CEF allows your designers to start building shippable product. The toughest thing I face when doing UI development is that I have no sense of what looks good, at all. Every time I do UI work I get a nice structure in place and I think it looks good, and then for that final 10% I have to have the team's designer sitting over my shoulder telling me 'Add Whitespace' ,'move that down 10 pixels' and generally torturing me. Don't get me wrong, I think it works and at the end I can see the difference and I can see that it is better, but I have no idea how to spot all those individual minor tweaks myself. I really want to be able to get the structure in place with some good design time data and then have the usability people do the final 10%. HTML and CSS are accessible enough that you don't need a software engineering background to make changes.

Next Time

Through these first 3 posts, I have given you an introduction to what motivated my investigation into replacing WPF and XAML with HTML5. We have also looked at how to structure your application and a popular pattern and some of the advantages that it brings.

In the next post I will take you through how I have actually built some of the apps that are using CEF and get our hands dirty with some code.

In my last post I outlined why I thought HTML5 is a better solution for building UIs than using WPF, however, my day job is building a plugin for Visual Studio forcing me to use WPF. I have been using the Chromium Embedded Framework (CEF) to see if it will allow me to bring the advantages of HTML5 to my application in a way that makes sense for me.

CEF is essentially the open source core of the Chrome web browser, repackaged as a library so you can include it in your own products. It allows you to host Chromium in your Windows, Mac or Linux application and has some very neat features that allow you to easily use HTML5 as the view layer in your application and still use whatever language or platform you want to actually build your application be it .NET, Cocoa or Python.

Below is the what I have come to think of as the standard architecture of a CEF application. Notice that you don’t need to include any server component and you are still building traditional desktop software.

This architecture allows me to build my view in HTML5 whilst keeping the rest of my product and core business logic in the platform of my choosing, which for my current product is C#.

When I first starting using CEF at work, some people were skeptical. Most people's experience of building UIs using browser technologies is in front-end web development, and that can definitely be a frustrating experience.

It seems that the most common annoyances when building a web application are brought on by the fact that you don't know which browser your user is going to be running. This leads to some challenges:

Lowest Common Denominator: You need to look at what browsers visitors to your site are likely to use and then build the site using the feature-set of that browser. For my team’s product site (http://vsnomad.com/), I think the oldest browser we realistically need to deal with is IE7 or IE8, but that still means you lose lots of the stuff that is really improving front end development like CSS3 and lightning fast JavaScript.

Browser Incompatibility: Even when you do choose a common set of features you can rely on, they often have subtle differences and quirks across browser implementations so it definitely isn't a case of write-once and then expect it to work in every browser.

So, why the hell would you want to inflict this on your development? Ordinarily, people weigh up these frustrations against the fact that you can get your product to anyone on the internet without installs or any hassle. Well, with CEF, you don't have to deal with any cross browser nonsense at all as you are shipping the browser so you completely control the environment. This means you know the user will be using a bleeding-edge browser: the one you shipped to them. This has the nice bonus that you only need to test once.

So there you have it, CEF provides you a way to ensure that your users have a standards compliant, modern browser on their machine and provides you with a platform for building your entire app’s UI using HTML5.

In the next post, I will look at how I have used the MVVM pattern, which is common in WPF codebases, with CEF.

My first draft of this blog post ended up being really critical of Windows Presentation Foundation (WPF) but on reflection I think it is unfair to criticise the technology too much. The technology world has always been fast moving, but since WPF’s release in 2006 some major changes have happened. The iPhone (2007) and Chrome (2008) were released, challenging Microsoft’s dominance over how people interact with computers. WPF has failed to keep up and I think people broadly agree that whilst a competent technology, it has many rough edges and hasn’t kept pace.

For a project at work, I began looking for alternatives to WPF and when someone suggested HTML5 as a view technology, I made some marking criteria to compare it to WPF.

Had to have a great developer experience

Both technologies provide you with a way to declaratively build a UI. However, WPF really only provides you with Visual Studio to use as an editor. Visual Studio is great for working with other programmers but working with designers has always been a struggle. Designers don’t know XAML and Microsoft’s vision of designers living in Expression Blend and developers living in Visual Studio didn’t materialise. However, designers do know HTML and CSS and are comfortable using a text editor of their choice to build up mockups, why can’t those mockups be turned into real products?

Actively developed

WPF has only had Microsoft really get behind it, whereas there are numerous companies backing HTML5, all for their own reasons but pragmatically, it means that the rate of change is greater and the risk of stagnation is quite low.

Large ecosystem

HTML5 has a much broader user base than WPF as the Web has more appeal than traditional desktop software. This has meant that there is an active community built up around HTML5 and JavaScript. No more relying on Microsoft to provide the entire solution, now there are multiple components that can be glued together to build your solution. Choose from Knockout, AngularJS, Backbone etc. etc. and use whatever you think best suits your way of working and the problem at hand.

Skills for the future

Personally I think that everything is moving to the web. This is pretty much inevitable and it will only be certain kinds of software that will remain in the traditional desktop form that we may be more used to. I am writing this blog post using the Office Web Apps whilst listening to the Spotify Web Player, I think the decision between investing my time learning WPF/XAML versus HTML5 is clear for me.

I have convinced myself that HTML5 is a suitable technology, but my day job project is a plugin for Visual Studio so doing a browser based application was out of the question. Does this mean that I am forced into sticking with WPF for now? In the next blog post I will talk about Chromium Embedded and how it provides a way for those of us writing desktop software to use modern technology.