DI

A logging library for operations or a C# feature which Java developer will appreciate

Wed, 16 Mar 2016 10:25:33 GMT

This blog is not about how Java is better than C# or vice versa. It's about using existing features a language offers you - every language has its own strength.

I went to London Continuous Delivery meetup a few weeks ago where Sean Reilly presented a logging library with operations in mind - opslogger. The library is created in Java and one of the questions was when it will be ported in .NET. In .NET we don't have to create a library for this purpose, we can extend existing libraries applying what C# language offers. If you’re a .NET developer then extension methods shouldn’t be new to you but if you’re an ops guy show this article to your devs.

The main idea of the library is that it does logging for operations. I really liked it and agree with the fact that people who look after our apps are left behind in terms of what to log. Although I think the logging is for both operations and developers. The first look after the performance and the behaviour and the latter came to the scene for troubleshooting.
The library is very opinionated, for example, you can't use different levels - there is just one level. You either log or you don't. There's no log rotation, and I agree with what Sean is saying that devops know how to configure it so you don't need a tool to do that. But, how about the applications you deploy on clients machines? In .NET world that will be Windows Forms and WPF applications. You need log rotation and you need different levels - you don't want to log everything every time on a client machine. Also, I like having different methods for logging: debug with some message and object to be serialized as parameters and a different method to log exception with Exception instance. For example:

Log.Debug("Request info", request);
Log.Error("Exception when executing payment", ex);

The idea I liked in the framework is that you don't log random messages but you have a set of predefined identifications plus your log message. For example, every time the application starts you log:

APP-001 Application started.

The code in the opslogger library looks like this:

logger.log(START_APP, "Application started.");

and START_APP is an enum with value "APP-0001"

If you're a .NET developer you know we can easily implement the same approach using existing logging libraries and extension methods. We have nice logging libraries with a vast amount of features. Why should we create one just for logging specific messages? What opslogger library does is that it uses a set identification messages.

I used to use log4net in the past, but I switched to NLog. If you're still using log4net I definitely recommend to have a look at NLog. In this example I will use NLog.

I have created a sample ASP.NET MVC application to prove the idea. You can find it on github.

We're going to extend NLog with a set of predefined methods with specific messages. For example:

 public static class LoggerExtension
    {
        public static void ActionInit(this ILogger logger, string message)
        {
            logger.Debug($"APP-001 {message}");
        }
        public static void Performance(this ILogger logger, string message)
        {
            logger.Debug($"PERFORMANCE-001 {message}");
        }
    }

And we'll use it like that:

Logger.ActionInit("HomeController Index");

Have a look at log output below. You can see that it's easy to search for particular messages. Let's say you want to filter all the performance logs, in this case you use PERFORMANCE-001 tag and depending what system you use to store logging you can have a nice filter/view of the data.

2016-03-10 14:04:26.1665|DEBUG|NLogExtension.Controllers.HomeController|APP-001 HomeController Index

2016-03-10 14:04:26.1860|DEBUG|NLogExtension.Controllers.HomeController|Get all users

2016-03-10 14:04:26.8906|DEBUG|NLogExtension.Controllers.HomeController|PERFORMANCE-001 Getting users in: 700

2016-03-10 14:04:26.8946|DEBUG|NLogExtension.Controllers.HomeController|Searching for active items

2016-03-10 14:04:27.1998|DEBUG|NLogExtension.Controllers.HomeController|PERFORMANCE-001 Searching active items in: 301

2016-03-10 14:04:27.2478|DEBUG|NLogExtension.Controllers.HomeController|Sample debug message

2016-03-10 14:10:06.0037|DEBUG|NLogExtension.Controllers.HomeController|APP-001 HomeController Index

2016-03-10 14:10:06.0322|DEBUG|NLogExtension.Controllers.HomeController|Get all users

2016-03-10 14:10:06.7354|DEBUG|NLogExtension.Controllers.HomeController|PERFORMANCE-001 Getting users in: 700

2016-03-10 14:10:06.7464|DEBUG|NLogExtension.Controllers.HomeController|Searching for active items

2016-03-10 14:10:07.0559|DEBUG|NLogExtension.Controllers.HomeController|PERFORMANCE-001 Searching active items in: 300

2016-03-10 14:10:07.0559|DEBUG|NLogExtension.Controllers.HomeController|Sample debug message

2016-03-10 14:10:07.5652|DEBUG|NLogExtension.Controllers.HomeController|APP-001 HomeController About

2016-03-10 14:10:08.8938|DEBUG|NLogExtension.Controllers.HomeController|APP-001 HomeController Contact

As you can see we can achieve the same output as opslogger with any logger library we want in a very flexible way.

Continuous Integration and Deployment of Azure Web App using VSTS / VSO

Thu, 25 Feb 2016 14:02:31 GMT

A new addition to the Microsoft’s Visual Studio Team Services (former VSO) continuous integration and deployment is the Release tool. The CI/CD process I’m describing here applies to VSTS but at some point it will be released to TFS as well. Microsoft invested its effort into building a nice continuous integration and deployment pipeline. The new online VSTS build and release tools are much better than the old XAML builds. I have been working with TeamCity for a very good number of years and I was surprised with Microsoft’s new addition. I started working with Build and Release tools very earlier for one of our clients - since private previews. It was called Visual Studio Online at that time. My experience is that they are moving very fast. I ported a few of our TeamCity builds and deployment configurations over to VSTS and it was easier than I expected. Taking into the account that I almost had zero documentation I progressed very quickly.

In this article I will explain how you can build and deploy a Web site into Azure Web App. VSTS contains a template for Azure Web Sites which makes our life easier. It contains Cloud Services and IIS Web Applications also. And if there’s anything you need which is missing you can always use PowerShell.

The solution we’re going to deploy represents an ASP.NET MVC Application but a WebForms application will have the same approach. For the sake of simplicity I created an ASP.NET MVC Application and named it OfficeInventory.

Create a build configuration

Open Build tab in VSTS and click the plus button:

Select an Empty template in the popup windows and click Next. There is a Visual Studio Template but it will add build steps which we don’t need, like Visual Studio Test and Index Sources.

In the next step select the source settings. Default agent in this case will be Hosted, unless you’ve installed your own agent. With the hosted agent you have 240 free minutes per month. Check Continuous Integration check box and click Create.

First we’ll configure the build and after that we’ll add build steps.

Repository configuration

We’ll come back and update the build and publish build steps but for the moment open the Repository tab. You should have already source settings in place. The settings I’m explaining below refer to a Git repository. If you want the build process to download all the source code every time it builds select true for the Clean dropdown. Depending how big your project is this may slow down the build process. If you want to tag your source code then select the appropriate value in the Label sources. Adding tags to you build will make sense when you create NuGet packages but it will provide less information for normal builds. By default Label format contains the build number. I will explain later how to set it.

Variables configuration

The Variables tab contains our variables definition we can use during the build process. We can use them in the following format:

$(VariableName)

Let’s add the following variables:

BuildConfiguration	Release
BuildPlatform	Any CPU

Triggers configuration

In the Triggers tab we can configure when to run the build. You can set it up to run as Continuous integration and include filters based on branch names. When you check Batch changes option it will include several check-ins if they are from the same committer. You can run the build on a schedule as well. Adding the schedule will help when you want to run builds which takes more time, like testing.

General

In the General tab you can change the Agent Queue, build authorisation, badge displayed on external web site etc. We’re interested in setting the Build Number.

I like setting the build number following the classic approach: major.minor.build.revision. In this case, if I want the build number to be 1.0.3.[RevisionNo] then I use the format 1.0.3.$(Rev:r). If you prefer to use a different system to name your builds, like using date, then find more information online at this MSDN link.

Retention

The Retention tab allows to specify for how many days you can keep the build details, including test results. The default value is 30 days and at the moment you can’t change that.

Build steps

We have created an empty build, now lets add the configuration we need. Click Add build step… in the list of Tasks select Build on the left hand side and search for Visual Studio Build. Click the Add button. Next select Utility on the left hand side and click the Add button of the Publish Build Artifacts. Now you can close the popup.

Build solution

Let’s go back to the Build tab and select Visual Studio Build. We need to provide settings on the right hand side. First of all, you may want to add a meaningful name to this step, so click on the pencil in the right hand side, above all the settings and enter the name you want.

The Solution text box contains **\*.sln – you can leave it like that or click on the ellipsis button and select the solution file from the tree.

MSBuild Arguments – we need to create a package which we’ll deploy later in Azure Web App. In order to do this we’ll use the command line

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=$(Build.StagingDirectory)\OfficeInventory

Pay attention to the PackageLocation parameter. This is where our package will be copied. We’ll use this path in the next step to publish the package. We use Build.Staging variable which is a predefined build variable. The package will be copied to staging directory of our build and in the OfficeInventory folder. The staging folder is generated by the build agent. Find more information about build and release variables at Use variables.

For the Platform and Configuration provide the variables we’ve created before: $(BuildPlatform) and $(BuildConfiguration).

Check the Clean checkbox if you want to start the build with all the files removed from previous builds.

Publish package

The next step is to publish the package so we can use it during the Release process. Select the Publish Build Artifacts step. In the Path to Publish enter $(Build.StagingDirectory)\OfficeInventory. For the Artifact Name provide a name you want. In my case it’s OfficeInventory. In the Artifact Type select Server unless you want to copy the package to a shared folder.

Now it’s time to save if you haven’t yet and run the build.

Release

Open the Release tab. As I’m writing this blog the Release is in public preview.

Click on the Plus button and select Azure Website Deployment. It will add a new environment with Azure Deployment and Visual Studio Test tasks for that environment.

Delete the Visual Studio Test because we’re not going to configure it – I will post another article about configuring Unit Testing.

You can rename the environment if you want to. Usually you’ll create a few environments, like Dev, Testing, Staging, etc.

Click on the Artifacts tab then click on the Link an artifact source. Select the build you want to link to. There is nothing to add on the Configuration tab so click on the Triggers tab. Check the Continuous deployment and select the artifact and the environment. In the General tab I will change the default name format to Office Inventory - 1.0.0.$(rev:r)

In order to deploy to Azure you need to configure the Azure subscription first. Click on the Manage link on Azure Subscription of the Azure Web App Deployment task. This will open a new page. On that page click on the New Service Endpoint and Select Azure from the list. This will open a modal windows where you need to enter Azure details. The easiest way to get that information is hovering you mouse on the exclamation icon and click on the publish settings file link. That will download the Azure publish settings file. That file is an XML file so open it in your favourite editor. I prefer to use Certificate Based instead the Credentials type because I don’t want people to enter their credentials. In any case, extract the information you need from the publish settings file, like Subscription Id, Name, etc. and click OK.

Let’s go back to the Environments page and click on the Refresh button on the right hand side of the Azure Subscription. Enter the name of your Azure Web App, select the location and the slot (Production or Staging). Click on the Ellipses button select the package.

Now we’re ready to deploy. Save the release and click on the Release button and next Create Release.

NOTE: You can rename the Tasks if you click the pencil on the right hand side of the task Title.

Now you can add multiple environments and continuously deploy to them.

Using Ninject with ASP.NET Web Api 2

Fri, 29 May 2015 16:00:00 GMT

Dependency Injection in Web Api 2 has changed. For this purpose the NuGet packages for Ninject has been updated adding some breaking changes. If you have used Ninject before and tried the same approach to Web Api 2 or you're updating your Web Api project then it might not work.

Adding the Ninject package is really simple but you need to know which packages to add.

The following packages should be added in the specified order. Open the NuGet Package Manager Console and add the following:

install-package Ninject.Web.WebApi
install-package Ninject.Web.WebApi.WebHost

Both libraries at the time of writing are 3.2.4.

You can install Ninject.Web.WebApi.WebHost only and it will install the Ninject.Web.WebApi as well. But in my case it installs Ninject.Web.WebApi.WebHost 3.2.4 but Ninject.Web.WebApi will be 3.2.0.0 because that's the minimum version Ninject.Web.WebApi.WebHost depends on. And this throws an HttpConfiguration activation error.

If you follow the two-step process described above it will work.

The file NinjectWebCommon will be added to the App_Start folder. You need to the RegisterServices method and add your binding, like this

kernel.Bind<IUserRepository>().To<UserRepository>();

I've created a sample project you can checkout https://github.com/ralbu/ninjectwithwebapi2