Not your daddy’s dotnet

Last Wednesday I gave a talk together with Rick van den Bosch about .Net Core, Asp.Net Core and EF Core. I did talks before but this one was in front of a crowd of about a hundred developers, it was filled with live coding/and demo’s and it was my first duo talk.


I is a lot of work to prepare for something like this, the scariest part was that Rick and I did not meet up to prepare until Wednesday afternoon. But in retrospective there was nothing to worry about because we were exactly on the same page.

The talk went alright, not really happy about my first demo’s though. We had some nice feedback and are even planning a follow up with a hands on workshop on the topic.

But now there is still all kinds of stuff to do. We have to pick a date and create labs for the workshop. We also had a competition for a seat in the  Troy Hunt workshop that we have in June, still need to pick the winner on that one. Yesterday Rick removed our speaker notes from the presentation and shared it on slideshare. Today I’m cleaning up our demo’s in our git repository to be able to share them on github.

Next week I can start focusing on the next big event on my schedule: Global Azure Bootcamp

[Update]: The code is on Github and we are organizing a workshop on Saturday afternoon the 20th of may. If you want to join it, send me a tweet @oscarvantol

Adding Application Insights to multiple WebApps

I’m working on a project that uses Angularjs on the front-end and uses a lot of REST services that are hosted in Azure on WebApps. We have split the domains of the project properly and detached all the external systems, this leaves me with about 15 WebApps. All these WebApps created an Application Insights account in the portal and it was time to hook them up. What I didn’t want is have 15 Application Insights accounts to look after and setup alerts for, after all it’s just one app.

So I went on and setup one new common AI account for the app and deleted the auto created ones. But I also didn’t want my dev and test environments to mix with my production environment, therefore I created an Application Insight account per environment and configuration. The link between the app and the application insights account is made by the InstrumentationKey in the ApplicationInsights.config. What I needed was that the InstrumentationKey is in my web.config because then I would be able to use my publish transforms.

How to use the instrumentation key from the web.config

First zero out the InstrumentationKey guid in the ApplicationInsights.config file. Next add an appsetting in the web.config named InstrumentationKey or something else that makes sense. Now we need to add some code, the code needs the run as early as possible and in my case that is in the Application_Start method in the Global.asax file. Add the following line of code:

Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey =

This sets the instrumentationkey of the active configuration to your appsetting. All you need to do now is set the appsetting transforms for the different configurations:

  <add key="InstrumentationKey" value="blablabl-abla-blab-labl-ablablablabl" xdt:Transform="Replace" xdt:Locator="Match(key)"/>

That’s all I guess. I’ve got a shiny dashboard with some cool stuff.

But wait!

I see some exceptions but when I click on them to find out what’s going on it says: “Learn how to track exceptions for failed requests” and gives an example of a try-catch block there. I’m not doing that for every method in all of my controllers!

Before I started typing away I bingled and found the next example: AiExceptionLogger.cs. You can put this in your project and in the Register method in the WebApiConfig.cs you can hook this in like this:

config.Services.Add(typeof(IExceptionLogger), new AiExceptionLogger());

And there you are, exception tracking in Application Insights.

Cool stuff: The new VSO Build system

Some time ago a new tab appeared in visual studio online called Build.Preview. For the project we are working on we use the VSO build system so it caught my attention. In our team we were running into some difficulties using continuous deployment of Azure WebApps with WebJobs. Also we didn’t like the way we were automatically pushing out nuget packages to our private MyGet feed. We created all sorts of scripts and custom templates, but it just seemend too complicated. Why should a build environment be harder to configure or debug than a local msbuild command?

Microsoft had pushed out the customizable cross platform build system that I was waiting for!

  • The build task is nothing more than msbuild.exe in a concole, and you get the output directly while running.
  • You can add a ‘deploy to Azure WebApps’ step to your build.
  • Adding a powershell script as a build step (and just about anything else that exists in the world!)
  • Debugging a build is simple, you can execute it on your local machine.

Let’s build and deploy an Azure WebApp with some webjobs

In visual studio online I clicked the big green plus button got a dialog with two tabs named build and deployment. I chose the deployment tab, selected Azure Website and pushed the ‘ok’ button.

BuildForm 1

This looks simple, a lot of stuff is already filled in. Under repository I changed the mappings so that only the right solution targeted for the build. I also set the configuration property because there are some transforms in my project. Under Triggers you can set up continuous integration for the build.

Next up, Azure Web Site Deployment. The line is red, it’s probably expecting some wisdom from me.

WebApp Deployment

First I selected my azure subscription that was already linked to visual studio online. After this I tried to select my target WebApp but the select box remained empty… Hmm, this doesn’t work, but wait I can type in there too. So next I filled in the name of my WebApp. (Not the full domain, just the name without

Saved it, named it and queued it!

I started the build in the hosted controller and got a cool powershell looking console. It started running and all was looking great until it got to the publish step.

##[error]Found more than one file to deploy with search pattern 'C:\a\a918231f\staging\**\*.zip'. There can be only one

Thinking about the error “More than one file to deploy” and smiling because of the highlander/mcloud joke in there. I got it, in the package property “*.zip” was defined by default. The default msbuild arguments “/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true” are responsible for creating this package on build.

Normally this would work but I’ve got some webjobs in my solution and it also creates packages for these. All the webjobs are also packed in the website package so I changed “*.zip” to a specific “”.

Next build and deploy was succesful!

Hello world!

Hello everyone, or just you…

I just created this wordpress site. I will be blogging here about things that are keeping me busy, mostly tech stuff regarding .Net, Azure and Scrum.