Video: How to create an Azure ARM template in Visual Studio 2015

2016-05-15_15-38-12I’m currently working on a Visual Studio ALM Rangers project to create an Azure ARM template that will deploy a secure SonarQube installation into Azure.  I found that there weren’t a lot of resources around how to get started with ARM templates in Visual Studio 2015.  In response I decided to create a walk-through.  I figured it would be easier for me to record a video of the process rather than try to write it out step-by-step.

The video is posted on Channel 9.

Let me know what you think of it in the comments here or there.

  • Steve

How To: Set VSO/TFS 2015 Build logging level to Verbose

This tidbit just came across my email and I know that I’m going to need it sometime in the future, so I’m blogging it for posterity.


The MSBuild and XAML build systems found in the Team Build feature of TFS and VSO have provided the ability to set the output logging level so that your logs would return excruciatingly detailed logs of every action in the build process.  This facility was implemented as a Property in MSBuild builds (/p:verbosity=diagnostic) and as a setting in the XAML build system (2. Basic -> Logging verbosity -> Detailed).  In the new build system in VSO and TFS 2015 there is no setting for this value.



To make the new build system return detailed log files you need to add a new variable to your Build Definition called system.debug with a value of true.

VSO Build Logging


Happy building! 🙂



How to: Create a custom toolbar menu in a VSO extension


Visual Studio Online (VSO) will support the creation of extensions that will allow a developer to extend the functionality provided to VSO users. The ability to extend VSO requires that you are part of the Visual Studio Partner program (which is free). For more information on writing VSO extensions check out VSO’s Integrate site.

I’m going to assume that you have been able to create a VSO extension that contributes an action to VSO.  If not, you will want to look at Create your first extension with Visual Studio for the background information.  Once you understand the basics, you are ready to jump in to something slightly more complex.  Creating a drop-down menu in a VSO extension requires a little bit of extra JavaScript but nothing difficult.  I’ve created a zip file with all of the code used in this post, so you could also just grab that code and I’ll walk you through the interesting parts.

At the end of this article you should be able to create a drop-down menu from a VSO work item toolbar as shown in Figure 1 and understand the mechanics behind creating VSO Extensions with these capabilities.


Step 1: Create a contribution point in the work item toolbar.

Start by opening the extension.json file.  This file holds the extension’s manifest as well as all of the contributions the extension provides to VSO.  The important piece is the contributions section in the following code:

{"namespace": "steve.workitemdemo","version": "0.0.1","name": "Work Item Manipulation Demo VSO Extension","description": "Demo","provider": {"name": "Steve St. Jean"   },   "baseUri": "https://localhost:44304",   "icon": "https://localhost:44304/images/steve-demo-icon.png",   "contributions": {      "": [         {         "id": "dupewi",         "text": "Duplicates",         "icon": "images/show-properties.png",         "group": "actions",         "uri": "main.html"         }      ]   }}

The contributions section is where you tell VSO where you want your menu to appear.  The value tells VSO that we want to create an action on the work item toolbar in the Work hub.  The work item toolbar is the toolbar in the Work Item form on the Queries hub as well as on the work item form when you open a work item as shown in Figures 2 & 3SNAGHTML21b60b0


The important attributes in the contribution definition for our purposes are id, group, and uri.

contributions": {   "": [      {      "id": "dupewi",      "text": "Duplicates",      "icon": "images/show-properties.png",      "group": "actions",      "uri": "main.html"      }   ]}

The id value is going to be our anchor point.  We will need to write some JavaScript to extend the toolbar.  That JavaScript will be inside the function that VSO will call when it looks for the definition of the dupewi contribution.

The group value tells VSO that dupewi is going to do something.  In our case it is going to display a menu.

The uri value tells VSO which page to call when it needs information about the dupewi action.

That’s all we need to get this hooked up.

Step 2: Define the dupewi menu in main.html

When VSO loads the Queries hub or loads a work item it will see that we have extended its functionality.  Our manifest says that the code to retrieve for the extension can be found in main.html.  VSO will call out and load main.html and begin processing the <script> tags on the page.  The key to creating our menu is in the VSS.register(“dupewi”) function.  VSS.register takes the name of the contribution point and an object that implements the IContributedMenuSource interface.  IContributedMenuSource has two members, execute() and getMenuItems().  Most of the demos out there simply use the execute() method to return a callback that will be run when the user clicks on the item in the toolbar.  To create the drop-down menus, we need to also use the getMenuItems() function to return an array of menu object which can each have a child array of menu items.

Typically, the VSS.register() for an action only has an execute() member.  This is because the information needed to render the toolbar item is stored in the extension.json manifest file.  All VSO needs in that case is the execute() function as a callback to invoke when the user clicks on our contribution as shown in Figure 4.


In our case, we want to completely override the contribution information set in the extension.json file with our own menu.  We are now using the dupewi contribution as a hook to get our code to run so that we can define the menu and sub-menus in code.

Figure 5 shows the getMenuItems() member of dupewi which contains a function that constructs our array of menu items and returns that array to VSO for rendering.


Now let’s look at how we construct the top-level menu.  We start off creating a variable called menuItems that will hold the array of object literals that describe our menus.  We then create our top-level menu item.  This is the item we will see on the toolbar when the drop-down menu is collapsed.

Notice in Figure 6 that the top-level menu’s id value is dupewi just like we had in our extensions.json file.  This causes our definition to override the definition found in extensions.json.

Notice that we are missing a text value.  The text value is used to render text next to the icon in the toolbar.  Since we don’t have a text value our contribution will render as an icon only.

The icon value points to the location of the icon graphic that will be show in the toolbar when the contribution is rendered and the title value will be rendered as the tooltip for the icon.

The childItems[] array of object literals where we create the sub-menus.


The childItems[] array contains three child menu object literals as shown in Figure 7.  Each child menu has a unique id, has a text value to display as the menu name, has an action() member which returns a callback function that will be triggered when the menu item is clicked, and contains an icon value which is empty in this case.


As of the date of this article there is a bug in VSO that requires the icon member to be defined even if it is not used. This is the reason you see the icon: “” text in the code in Figure 7.  If the icon member is not present then VSO will fail to render the entire contribution.  This bug has been fixed but the new code has not been rolled out to all of the VSO scale units as of 18-July-2015.



That’s it.  Creating the child menus is as simple as defining a contribution point in the extension.json file and then using the VSS.register() function to generate a new set of menu items for VSO to display.  After you have deployed your extension to your web server and upload your extension.json to your VSO account you should be seeing your top-level menu appear in the work item toolbar.


The code for this article can be downloaded from here:

Twitter and Bitly Plugin for Windows Live Writer 2012

Twitter-IconI’ve been playing around with the new WordPress blog, mostly getting it setup with my favorite blog editor Windows Live Writer.  I’ve used this tool in the past with great success. 

One of the nice things about WLW is that is has a nice plugin model.  One of the plugins that I used to use constantly is the Twitter plugin.  That plugin would post a tweet containing the blog title and a link right after you published the blog post to your site.  Unfortunately, I can’t seem to find that plugin anywhere on the Internet so I decided to cobble together my own. 

This is version 0.6.0, meaning that it is Beta software and hasn’t been tested extensively.  It works on my machine but I don’t guarantee that it will work on yours.  My development philosophy is “Make it work”, “Make it work right”, “Make it work well”.  This is definitely in the “Make it work” phase.  I need to add more error handling on the various web calls.pufferfishIconWriter

If you want to take a copy and use it/test it out for me I’d be grateful.  I’ve created a static page on my blog for the plugin so feel free to go there, download the plugin, and leave any feedback in the comments for that post (or here).

Here’s the page address:

Moved to WordPess on Azure PaaS and Azure SQL


I’ve moved my blog to a new blogging engine. I’ve migrated all of the old posts. I won’t be setting up any handlers for the old URLs, so the old permalinks will probably 404 on you.

The long form

As you may have noticed, this blog looks and feel different.  I’ve moved the blog through a series of blog engines to get to this point. The blog started out on Blogger and was there for years.

After moving to Microsoft I decided it was time to use the tools and platforms that we make.  I also decided that it was time to get back into writing code at least part of each day.  To that end I decided to grab Mads Kristensen’s  MiniBlog blogging engine source code and deploy it into an Azure Platform-as-a-Service (PaaS) web site.  This worked out well for a while but I found that I was spending more time tweaking the code and the site than thinking about and writing blog posts.  As you can see from my blog history, I posted zero times while on MiniBlog.  This should not be taken as a negative against MiniBlog.  It is a great blogging engine.  Rather I just found writing code more fun than writing the blog.

Since I really want to get back to blogging, I decided to give up MiniBlog for WordPress since I don’t know a damn thing about PHP and MYSQL.  I started out by launching the Azure Portal and creating a new Web App and selected WordPress from the Azure Gallery.


Unfortunately, MySQL in Azure is managed by ClearDB and billed separately.  I was hoping that I would be able to select Azure SQL as the backend for WordPress but that was never an option.  So what’s a guy to do.  I could either continue using MySQL as the database or I could ask my colleagues in the Premier Support for Developers team what they us and if any of them have experience with WordPress.  It just so happens that one of my colleagues uses WordPress on Azure SQL through Project Nami.

Project Nami is a fork of WordPress that is built for self-hosting in Azure or on-premises using a SQL Server or SQL Azure database.

In their own words

And that moment, when we realized that SQL Azure now had proper replacements for all required functions, is when we decided to fork WordPress.  In a matter of weeks, Project Nami (Not Another MySQL Interpreter) was born.

Project Nami has a single initial goal — to teach WordPress to natively speak MSSQL while maintaining full compatibility with properly written plugins and themes.  This is an important item to note.  Any plugin, theme, or function written to access the database via the WordPress API will operate normally.
– Project Nami Team

Installation is EXTREMELY easy if you already have an Azure subscription.  Just go to the Project Nami download page and click the blue button that says “Deploy to Azure”.


About five minutes later I was up and running. That’s all it took.

If you are looking for a blogging engine running on Azure Paas with a SQL Azure database there are a couple of options, but this WordPress / Project Nami site was easy to deploy and configure. I have to give it high marks so far.