Friday, May 30, 2014

Azure implementation guidelines

In My post ‘Service Bus Management’ I pointed out a way of implementing a DTAP strategy for managing the Service Bus environment. There’s now a great post available from Microsoft which goes into more detail about other aspects of managing the Azure subscriptions and other artefacts which is quite useful when setting up your Azure environments.

Follow this link to the ‘Azure Implementation Guidelines’



Friday, May 23, 2014

Increase your API usability by teaming up NuGet and Visual Studio

Tags van Technorati:

In my previous post I described a way to use NuGet for packaging libraries, often used in projects. This post is an addendum to my post ‘enter 2014 with NuGet’ look at the additional features possible. In this post i’m looking into Visual Studio features (project templates) and the NuGet package feature PowerShell.

I’ve been working on an API (see my next posts, Service Bus Series - ‘the case for service bus’), and during the development I wanted to make sure that explaining the API to another co-worker was a nicer experience than just going through the code. To ensure that the developers could easily connect and understand the usage of the API, I decided to create sample projects using templates. Templates are a great way to provide the user with a sample project from within Visual Studio. I wanted more… and with the features available in NuGet packages, i’ve found a way that worked for my scenario. I’ve been using the principles;

  1. Each project in Visual Studio can be exported as a template
  2. New Projects can be created based on a template, the user get the template in his overview of available project types
  3. Exporting templates results in a .Zip file in the <UserProfile> \ Documents \ Visual Studio <version> \ Templates \ Project Templates directory .
  4. NuGet allows by means of a 'Tools' content type to perform custom actions, which are executed when creating a reference of the NuGet package from PowerShell

By combining #1-3 with #4 we can create a NuGet package which adds a project template to the user of the NuGet package. This can be simply done by following the steps mentioned below;




  • Export Template


In Visual Studio select ‘File’ \ ‘Export Templates’ (in the solution which contains the project to be exported as template)

    1. Select the type ‘Project template’
    2. Select the project


3. Go Through the wizard steps


Note: This .zip file can be used in a different Visual Studio environment


Files can be added into a NuGet package, using the Content folder. In the NuGet package Explorer we can add a template;

1. Add a content folder


2. Add the content


3. Browse to the exported template


4. The endresult in the package explorer



  • NuGet and PowerShell

The final step is the configuration of a PowerShell script, which allows the Content to be installed in the folder of the user so that the project template is available. For this we need to perform the steps;

1. Add a tools folder


2. Add Install.ps1 (which is executed when you install the package


2. Add Install.ps1 (which is executed when you install the package) and add the following script


Note: This script will install the package into the user templates folder, and assumes (visual studio version, zipfile name)

Note 2: the complete script is copied below;

param($installPath, $toolsPath, $package, $project)
$documents = [System.IO.Path]::Combine((Get-Item env:USERPROFILE).Value, "Documents\Visual Studio 2013\Templates\ProjectTemplates")
$templateFile = ""
$template = [System.IO.Path]::Combine([System.IO.Path]::GetDirectoryName($project.FileName), $templateFile)
$templateDestination = [System.IO.Path]::Combine($documents, $templateFile)
Copy-Item $template $templateDestination

  • The endresult

Assuming the package is exported into the NuGet repository, the NuGet package source is configured, a new solution has been created, we can now use the package.

1. Manage NuGetPackages and click install


The PowerShell script is executed;



2. From now on we can create a sample project based on the template




If you are commited to re-using packages, and want to create an API or reusable library, this can be quite helpful. Although integrating NuGet in TFS is different, all the features presented are available, so improving the Dev-Ops integration using TFS is a nice way to improve this proces.

For me, this allowed me to provide more assistence to the end user of the API. I’ve currently devided the API into an package and created another package with the Templates. This post just gives an overview of the power that you have with NuGet.




Thursday, April 10, 2014

New Azure Portal – Preview

The new Azure Portal (in preview) is really great. Bundles a lot of the functionality that is sometimes hard to retrieve

  • Azure Health (e.g. BizTalk Services / Service Bus)
  • Billing information
  • View your resources (at this moment only Resource Groups / WebSites / Team Projects / SQL Databases / MySQL Databases)
  • Notifications (the alert functionality)
  • The concept of ‘Journeys’ (preselection filters you’ve implicitly placed so that you can quickly look at the dashboard the way you want)

Some screenshots to show how much more insight this provides…

Azure Health



Billing information


View your resources (at this moment only Resource Groups / WebSites / Team Projects / SQL Databases / MySQL Databases)




Journeys (preselection filters you’ve implicitly placed so that you can quickly look at the dashboard the way you want)



The portal brings a lot of features together that had to be done using different areas, like the billing portal, which only showed a few billing details, where an excel file was the only way to retrieve details, and the Azure health, which was located somewhere else.

So far, a great portal for a preview!




Wednesday, April 09, 2014

Add project reference? Enter 2014….Using NuGet for packaging projects and dependencies


[UPDATE] Sample solution available on OneDrive (

A solution consists of projects, projects uses components, components are of a specific version, changing the components thus requires a versioning strategy….which one are you using? All solutions which are architected into several tiers, have a form of layering with (which I hope) an abstraction of re-usable components. A project which is used to implement automated order approvals (AOA), with a requirement to implement logging, and retrieve something out of the database will likely have the minimum of 3 projects

  • Solution AOA
    • Project - AOA.Core
    • Project - AOA.DataProject
    • Project - Common.Logging

Let’s assume, that the Logging library is also used by another solution: BOB

  • Solution BOB
    • Project – BOB.Core
    • Project – BOB DataProject
    • Project - Common.Logging

When the requirements of logging change, and the project BOB needs a specific change due to legislation requirements. What options do we have to make sure that either the AOA solution does not break because it’s automatically using the latest version?

  1. Using the latest version of all the projects / components (e.g. using a build server)
    • Project approach: using project references to existing / local projects
    • Risk: the latest version has breaking changes
  2. Using a specific version by copying the dll to a local solution folder
    • Project approach: using local dll references
    • Risk: Managing the versions will lead to an enormous spreadsheet
  3. Using a SharedAssemblies folder which contains the latest version
    • Project approach: using Shared dll references
    • Risk: Managing the versions will lead to an enormous spreadsheet

Basically, we don’t know which version is used, we don’t control any of this, and the solutions provided are not sufficient. Enter NuGet….


So NuGet can be used to overcome this problem, by packaging components, versioning and even manage dependencies. When a project has a dependency and another component, it is possible to define this relationship in a NuGet package, and by doing this, retrieving the NuGet package, will automatically retrieve the dependent package. This allows you to ensure that the correct versions are retrieved, and the self-created dll-hell can be mitigated.

How can we do this? (example feed and solution can be found at:

Our client Contoso is developing a solution, which makes use of the Contoso.SB.Library. This library provides functionality in conjunction with the Azure Service Bus Library, providing automatic property promotion used to enable ‘automatic’ topics/subscriptions (just a example, of a solution that might exist Knipogende emoticon).

1. ProjectReference

This API is referenced by using a project reference, so the latest version of the SB.Library is always used….we would like to have more control. For this we can create a custom package, using the tool ‘NuGet Package Explorer’. Using this tool, it is possible to create a NuGet package of the Contoso.SB.Library, and be able to manage the used 3rd-party references, versioning and implement a changemanagement process.

We can create a new project

2. PackageExplorer

We then need to define the properties (my colleague Sybren Kuiper is working on a NuGet Packager which automatically retrieves this information from the project file), at this moment, we need to do this manually.

3. PackageLibrary

The Contoso.SB.Library uses the ServiceBus.v1_1 NuGet Package, so we need to add this dependency. This means that adding a reference to the Contoso.SB.Library will automatically retrieve the ServiceBus.v1_1 package.

4. PackageLibraryAddReference

Here you see the dependency defined in the Contoso.SB.Library

5. PackageLibraryDependencies

At this moment we only have a skeleton, we can now add the Library by adding a Lib Folder:

6. PackageLibraryAddLib

And add the Dll by adding an existing file

7. PackageLibraryAddExisting

Select the dll…

8. PackageLibraryAddExisting2

And save the package…

9. PackageSave

We can publish the package to a feed, such as NuGet.Org, but we can also simply use a file share to build our own private NuGet repository. In this case the repository is ‘C:\Temp\NuGetFeed’, this should offcourse be a UNC Path.

10. FeedSave



Click on: Tool\NuGet Package Manager \ Package Manager Settings

11. FeedConfig1

Add a new feed, and specify the path, for example our repository in ‘C:\Temp\NuGetFeed’:

12. FeedConfig2

In the solution we can now manage the NuGet packages for the solution;

13. MAnageNuGet

And add a reference to the Service Bus Library Functions, notice the dependencies (my colleague Sybren Kuiper is working on a NuGet HelpFile builder, which automatically generates a SandCastle help file, from the project file, which is then used in the NuGet package so that the help is available in this window), at this moment, we need to do this manually.

14. NuGetReference

As we can see, the dependency leads to the installation of the ServiceBus.v1_1, the version WE specified!

15. NuGetReference2

Restrictions may apply

16. LicenseAccept

So far….the same reference, only more work? No…

What we did, was abstracted the versioning and dependencies out of the solution. This means that the package is in control of the dependencies and not the project. This allows for a managed release of components, AND, new versions are available in a notification menu. This can be automated, used in a TFS build, etc.


What happens if we release a new version of the component? (using the NuGet Package Explorer)…

17. UpdatePackage

We can save the new version, where the name is generated based on the specified version (at this moment manually). This allows us to have control of which version is used in our project, as we can always go back to a previous version. In this case we would like to see that the project using version 1.0.0 still works, and that we get an update that there a new version. So we are going to save the new version, alongside the existing version.

18. UpdateVersion


If we manage the NuGet Packages for the solution, we now see that there is an installed version 1.0.0 and that there is an update, when it was published, and the new version 1.0.1. This can be automated, so that we have an overview of the used versions. In this case, we can simply click ‘Update’ to retrieve the new version.

19. UpdateVersion2

To be able to communicate with the Service Bus, we need several references, and by using the NuGet Packaging solution, we can ensure that we always have the version we need.

20. ReferencesEndResult


There you go, versioning strategy in place….governance fase 1 completed…get the TFS guy and set up the rest….

Some tips:

  • The NuGet packages can provide significant added value to components which are used in project, however not always during development
  • Conditional dependencies can be usefull
  • Added source/content such as sample can also be delivered using Project Templates which are problably more helpfull