The past few days I worked quite a lot with docker-compose on my windows machine and after something strange happened to my machine that crashed it, I was not able to start any containers anymore that had connectivity over the network with each other.

Every time I used the command-line docker-compose up, I would get a message telling me it failed to start the container. the full message I got was:

“ERROR: for web  Cannot start service web: failed to create endpoint aspnetblogapplication_web_1 on network nat: HNS failed with error : Unspecified error”

Read more →

Recently Microsoft added the capability to CodedUI to test on the Edge browser. For this they extended the cross browser playback capability. This uses Selenium under the hood. So the steps to make this work are as follows:

• Install the plugin “Selenium components for Coded UI Cross Browser Testing” from the Visual Studio Gallery (found here)
• Download the Edge driver that matches your windows 10 version (found here)
• Install the driver to the following location : %ProgramFiles(x86)%Microsoft Web Driver

And finally in the code you need to switch the browser you want to launch. You need to provide the following name to start edge:”MicrosoftEdge”

BrowserWindow.CurrentBrowser = “MicrosoftEdge”; 

var browserWindow = 
    BrowserWindow.Launch(new Uri("<your URl here>"));

And that is it!

Happy testing on Edge

If you attended one of my sessions, I hope you enjoyed them. I had a great time.

For your reference you can find the PDF’s here and the accompanying demo code.

Continuous delivery on azure: A/B testing, Canary releasing and Dark launching

If you are more interested in Continuous delivery, you also might like my just published course at Pluralsight called “Building a Continuous Delivery Pipeline with TFS and Visual Studio 2015” which you can find here: https://www.pluralsight.com/courses/tfs-visual-studio-2015-implementing-continuous-delivery

My second session was on Micro Services and you can find the PDF here:

VSH11 Exploring Microservices in a Microsoft Landscape

And the final session was on building maintainable cross browser UI tests with either selenium or codedUI. The PDF can be found here:

VSH16 Writing Maintainable X-Browser Automated Tests

and you can find the demo’s here: Search google

Also if you want to learn more about CodedUI, you can also watch one of my two courses I build for Pluralsight here:Test Automation with CodedUI Pluralsight which explains in detail all that can be done with CodedUI and Testing Web Applications with CodedUI Pluralsight which is focused on testing web applications.

if you don’t have a subscription yet, you can watch it for free with the free trial

Hope you enjoyed it, if you have comments or feedback let me know!

Cheers,

Marcel

Last week I presented two talks at Devintersection europe. My first talk was about Modern Application architectures and you can find the pdf of the deck here

the second session was on Cross browser testing of web applications using CodedUI. I also have the pdf of the deck available here

And here are the two demo’s I showed to build maintainable test automation using Page Objects and the concept of DAMP testing (Descriptive And Meaningful Phrases).

Search Google

MVC Music Store

Also if you want to learn more about CodedUI, you can also watch one of my two courses I build for Pluralsight here:Test Automation with CodedUI Pluralsight which explains in detail all that can be done with CodedUI and Testing Web Applications with CodedUI Pluralsight which is focused on testing web applications.

Hope this helps!

In my previous post about Deploying ASP.NET 4.5 to Docker on Windows I forgot to mention that you might run into an issue when running webdeploy.

Julian Perrott, commented on my post and asked if this is an issue. I think it is an issue and that the install does not complete correctly. But there is an easy fix for this as well. What you can do is add a small PowerShell script to your Docker image and run that after the first attempt to deploy the website. Then the next step is to run the script to fix the ACL’s and then again run web deploy. I have not yet tried this on the latest Windows server 2016 bits, but on the Technical preview 5 this worked like a charm.

You need the following script to fix the ACL’s:

$path = "C:inetpubwwwrootMvcMusicStore_deploy"
$acl = Get-Acl $path
Set-Acl $path $acl

This script doe nothing more then getting the ACL on the path and then re-apply it. this will make windows fix the ACL and make them in canonical form again.

You can add this to your dockerfile and make it part of your standard install of a website in your release pipeline.

FROM windowsserveriisaspnetwebdeploy 
RUN mkdir c:webapplication
WORKDIR /webapplication
ADD fixAcls.ps1 /MvcMusicStore/fixAcls.ps1
ADD dockerdeploydemo.zip  /webapplication/dockerdeploydemo.zip
ADD dockerdeploydemo.deploy.cmd /webapplication/dockerdeploydemo.deploy.cmd
ADD dockerdeploydemo.SetParameters.xml /webapplication/dockerdeploydemo.SetParameters.xml
RUN dockerdeploydemo.deploy.cmd, /Y
RUN powershell.exe -executionpolicy bypass .fixAcls.ps1
RUN dockerdeploydemo.deploy.cmd, /Y

So this does nothing more then adding the little PowerShell script to the container and then using that in the step after deploying your website

Hope this helps!

In preparation for Tech Days 2016, I was working with my colleagues on the Techdays app and for this we also have a backend system. This system is running for some time now and we want to have better insights into the usage of the website and the mobile app.

One of the latest additions to application insights is the capability of Live Metrics, where you can see the current traffic coming into your website or API.

For this you can simply add a NuGet package, which is currently in pre-release, but works great.

Once you install the package and run the website, you will see the Live Stream tile light up in the Azure portal and when you click it you will see a couple of live graphs showing actual traffic on the site or API

Of course we wanted to host our backend very simply on Azure Web apps and for this specific purpose on Azure Mobile Services, Since that is what we use as the mobile backend of the application. But apparently there are some subtle differences that prevent AppInsights to work properly if it comes to Live Metrics.

When running the web API on a local machine with app insights enabled, we could see a nice set of graphs as shown here below:

But when I deploy this to the Azure Mobile services, this results in a page that only shows the dependency calls, bet never any incoming requests and also no request duration. You only see a first request and after this the incoming requests are a flat liner.

After some inquiries at the app insights team, I got the information that since Azure Mobile Services is using OWIN, because the app insights HTTP modules are not loaded since that is not allowed and finally because performance counters are not exposed to the web application, these metrics will not show. After going back and forth on this, I got information that it would be possible to at least get the info for the requests on the screen, by adding a small piece of middleware, that can track the request instead of the standard HttpModule that is normally instantiated, but not allowed in a Mobile app.

So the only thing I needed to do is create a middleware component like the following:

public class ApplicationInsightsMobileAppRequestHandler : OwinMiddleware
{
   private readonly TelemetryClient telemetryClient;
   public ApplicationInsightsMobileAppRequestHandler(OwinMiddleware next) : base(next)
   {
    try
    {
      // The call initializes TelemetryConfiguration that will create and Intialize modules
      TelemetryConfiguration configuration = TelemetryConfiguration.Active;
      telemetryClient = new TelemetryClient(configuration);
    }
    catch (Exception exc)
    {
      Trace.WriteLine("Error initializing Handler");
      Trace.WriteLine(exc.Message);
    }
}

public override async Task Invoke(IOwinContext context)
{
  var operation = telemetryClient.StartOperation<RequestTelemetry>(context.Request.Path.Value);
  try
  {
    var requestTelemetry = operation.Telemetry;
    await this.Next.Invoke(context);
    requestTelemetry.HttpMethod = context.Request.Method;
    requestTelemetry.Url = context.Request.Uri;
    requestTelemetry.ResponseCode = context.Response.StatusCode.ToString();
    requestTelemetry.Success = context.Response.StatusCode >= 200 && context.Response.StatusCode < 300; 
  }
  catch (Exception exc)
  {
    var telemetry = new ExceptionTelemetry(exc);
    telemetry.HandledAt = ExceptionHandledAt.Unhandled;
    telemetryClient.TrackException(telemetry);
  }
  finally
  {
    telemetryClient.StopOperation(operation);
  }
 }
}

And an extension method to register the middleware in the request pipeline at startup in the Startup class:

public static class AppBuilderExtensions
{
  public static IAppBuilder UseMobileAppRequestHandler(this IAppBuilder app)
  {
     return app.Use<ApplicationInsightsMobileAppRequestHandler>();
  }
}

In the application startup class, ensure that you register this handler as the first as follows:

public static void ConfigureMobileApp(IAppBuilder app)
{
  HttpConfiguration config = new HttpConfiguration();
  app.UseMobileAppRequestHandler();
  app.UseWebApi(config);
  ConfigureSwagger(config);
}

And that is it!

When you now deploy tot the azure mobile app, you will see the live metrics as we expect. We still don’t have the memory consumption and CPU usage stats, but this now at least shows all incoming requests in real time

Hope this helps!

Marcel

In my previous post I showed you how you can create a docker container image that has an ASP.NET 4.5 website running on the full .NET framework. In this post I want to show you how you can use VSTS build V-next and the release management tools to leverage the docker technology.

Let us first start by creating a docker image as the result of our build, that we then later can use in the deployment pipeline to very easily run the website from the container and run some UI tests on them.

Creating the docker image that has the website, from the build

When we want to use docker as part of our build, then we need the build agent to run on a host that has the docker capabilities build in. For this we can use either windows 10 anniversary edition, or we can use windows server 2016 Technical preview 5. In my example I choose windows server 2016 TP5, since it is available from the azure gallery and gives a very simple setup. You choose the Windows server 2016 TP5 with containers as the base server and after you provision this in azure you download the build agent from VSTS and install it on the local server. After the agent is running, we can now create a build that contains several commands to create the container image.

First we need to ensure the build produces the required webdeploy package and accompanying artefacts and we place those in the artifact staging area. This is simply done by adding the following msbuild arguments to the build solution task that is part of a standard Visual Studio build template.

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=$(build.stagingDirectory)

Then after we are done creating the package and copying the files to the artifacts staging location, we then add an additional copy task that copies the docker files I described in my previous post to the artifacts staging directory, so they become part of the output of my build. I put the docker files in my Git repo, so they are part of every build and versioned.

After copying the docker files, we then add a couple of command line tasks that we will look at in more detail.

In the following screenshot you can see the additional build steps I used to make this work. The first extra command I added is the docker build command to build the image based on the dockerfile I described in my previous post. I just added the dockerfile to the Git repository as you normally do with all the infrastructure scripts you might have. The docker file contains the correct naming of the package that we produce in the build solution task.

You see me passing in the arguments like I did in the previous post, to give the image a tag that I can use later in my release pipeline to run the image.

You see I am using a variable $(GitVersion.NugetVersionV2). this variable is available to me because I use the task GitVersion that you can get from the marketplace. GitVersion determines the semantic version of the current build, based on your branch and changes and this is override able by using git commit messages. For more info on this task and how it works you can go here

Now after I create the image, I also want to be able to use it on any of my machines, by using the dockerhub as a repository for my images. So the next step is to login to dockerhub

After I have logged in to dockerhub, I can now push the newly created image to the repository.

And now we are done with our build. Next is using the image in our release pipeline

Running a docker image in the release pipeline

Now I go to release management and create a new release definition. What I need to do to run the docker container, is I need the release agent to run on the docker capable machine, exactly the same as with the build. Next we can then issue commands on that machine to run the image and it will pull it from dockerhub when not found on the local machine. Here you can see the release pipeline with two environments, test and production.

As you can see the first step is nothing more then issuing the docker run command and mapping the port 80 of the container to 80 on the machine. We Also use the –detach option, since we don’t want the agent to be blocked on running the container, so this starts the container and releases control back to the release agent. I also pass it in a name, so I can use the same name in a later stage to stop the image and remove it.

Next I run a set of CodedUI tests to validate if my website is running as expected and then I use the following docker command to stop the container:

docker stop $(docker.processname)

the variable $(docker.processname) is just a variable I defined for this release template and just contains an arbitrary name that I can then use cross multiple steps.

Finally I am running the command to remove the container after use. This ensures I can run the pipeline again with a new image after the next build

For this I use the docker command:

docker rm –f $(docker.processname)

I used the –f flag,  and I set the task to always run, so I am guaranteed this image is removed and even after a non successful release. this ensures the repeatability of the process which is of course very important.

Summary

As you can see it is quite easy to build containers during the build and use them in the release pipeline. I now used simple command line tasks to do the job, I assume it is just a matter of time before we will see some docker specific tasks in the marketplace for us to use. Microsoft has docker tasks in the marketplace, but these are only targeting Linux (at the moment I am writing this) and require a Linux docker machine connection to work. In my example here I am focused on leveraging docker on Windows and for this I hope we can see tasks in the future.

At the moment of this writing you can search the internet on ASP.NET and docker and all you will find is how to deploy ASP.NET Core applications to a Linux docker container. Although I love the initiative of ASP.NET core, I do believe that ASP.NET 4.5 is something many of you know and love already and nobody talks about how we can leverage docker on windows to run this full version of ASP.NET

To get you started we need to have a Windows version that is capable of natively running docker. With natively running docker I mean that docker is build into the OS. So no use of docker for windows tools, since we don’t want Linux containers, we want to run windows containers! At this moment you can use Windows 10 Anniversary edition and Windows Server 2016 Technical Preview 5 to go through the steps that I describe here to get your ASP.NET 4.5 website running in a docker on windows container.

What do we need to rollout an ASP.NET website to a windows docker container?

When you run an ASP.NET 4.5 website then you need the following things:

• The Operating system with IIS installed
• ASP.NET 4.5 installed
• Webdeploy installed

I personally love to use web deploy to deploy the website after build, so it can be done exactly the same way as you would deploy to Azure App Services or your local IIS Server on any server you already know and love.

Building the container with IIS, ASP.NET and Webdeploy

Here are the steps you need to take to create a docker container that has all these required ingredients:

Fist we need a basic operating system image from docker hub. For this you can run the following command from the command line:

docker pull microsoft/windowsservercore

now we have the image in our images gallery, you can check this with the following command:

docker images

This should output something similar to the following screenshot:

Now we can start adding the first layer and that is installing IIS. For this you can use the dism command on windows and pass it in the arguments to install the IIS webserver role to windows server core. You can do this at an interactive prompt or use the docker build command. I prefer the later and for this we create a dockerfile that contains the following statements:

FROM microsoft/windowsservercore 

RUN dism /online /enable-feature /all /featurename:iis-webserver /NoRestart

After saving the file under the name dockerfile without any extensions you run a command line to build the image:

docker build -t windowsserveriis .

The command tells docker to build an image, give it the tag windowsserveriis and use the current folder (denoted with the dot) as the context to build the image. this means that everything stated in the dockerfile is relative to that context. Note that you are only allowed to use lowercase characters for the tagename.

After running the command you now have a new docker image with the name windowsserveriis

If you now run the command:

docker images

you will see the new image available

We can take the next step and that is to install ASP.NET 4.5

We can do this in a similar way, by creating a docker file with the following commands:

FROM windowsserveriis
RUN  dism /online /enable-feature /featurename:IIS-ASPNET45

and again after saving the file you can run the command line to build the image:

docker build –t windowsserveriisaspnet .

Now we have an image that is capable of running an ASP.NET application. The next step is that we need webdepoy to be installed in the container. For this we need to download the installer for webdeploy and then issue an command that will install and wait for the installation to finish. We first download the installer in the same folder as the dockerfile and then we will add it to the image. In the following steps I assume you already downloaded the MSI (WebDeploy_2_10_amd64_en-US.msi) and have it in the same folder as the dockerfile. When installing the msi we will use msiexec and need to start a process that we can wait on to be done. If we would only run msiexec, then this command returns and runs in the background, making the container to exit, leaving us in an undefined state.

When you create the following dockerfile, you install webdeploy:

FROM windowsserveriisaspnet
RUN mkdir c:install
ADD WebDeploy_2_10_amd64_en-US.msi /install/WebDeploy_2_10_amd64_en-US.msi
WORKDIR /install
RUN powershell start-Process msiexec.exe -ArgumentList '/i c:installWebDeploy_2_10_amd64_en-US.msi /qn' -Wait

Note that we are using powershell start-process with the –wait option, so we wait for the installation to finish, before we commit the new layer.

Now run the docker command again to build the image using the new dockerfile:

docker build –t windowsserveriisaspnetwebdeploy .

Now we have an image that is capable to host our website in IIS and use webdeploy to install our website.

Doing it all in one dockerfile

In the previous steps we created a new docker file for each step. But it is probably better to do this in one file, batching all commands together leaving you with the same endstate. We can also optimize the process a bit, since Microsoft already provides an image called microsoft/iis that has the iis feature enabled. This means we can use that image as the base layer and skip the install of IIS.

The simplified docker file looks as follows:

FROM microsoft/iis
RUN dism /online /enable-feature /all /featurename:iis-webserver /NoRestart
RUN mkdir c:install
ADD WebDeploy_2_10_amd64_en-US.msi /install/WebDeploy_2_10_amd64_en-US.msi
WORKDIR /install
RUN powershell start-Process msiexec.exe -ArgumentList '/i c:installWebDeploy_2_10_amd64_en-US.msi /qn' -Wait

Now again we run the docker build command to get the docker image capable of running our website and use the webdeploy packages that can be produced by a standard ASP.NET build procedure.

docker build –t windowsserveriisaspnetwebdeploy .

The final step is to deploy your webdeploy package to the image.

Getting the webdeploy package

Now before we can deploy our website we need to get the webdeploy package.

I assume you have a standard ASP.NET web project in Visual Studio. In this case you can very easily create the deploy package inside Visual Studio (in the next post I show you how to do this using VSTS/TFS builds)

When you right click the Visual Studio project you can select the publish option:

After selecting publish you will see the following dialog:

In order to just create a package in stead of deploying to a server or Azure, I select Custom

then you give the profile a name, in my case dockerdeploydemo

then we select web deploy package from the dropdown and provide the required information, package location and the name of the website

next you can setup any database connections if you have any, in my case I have no database

next, click publish and you will find the resulting deployment package and accompanying deployment files in the c:temp folder

Now that we have the webdeploy package and the accompanying deployment artifacts, we can again create a docker file that will then upload the package to the container and install the website in the container. This will then leave you with a complete docker image that runs your website.

Publish the website in the docker container

The dockerfile to deploy your website looks as follows:

FROM windowsserveriisaspnetwebdeploy 
RUN mkdir c:webapplication
WORKDIR /webapplication
ADD dockerdeploydemo.zip  /webapplication/dockerdeploydemo.zip
ADD dockerdeploydemo.deploy.cmd /webapplication/dockerdeploydemo.deploy.cmd
ADD dockerdeploydemo.SetParameters.xml /webapplication/dockerdeploydemo.SetParameters.xml
RUN dockerdeploydemo.deploy.cmd, /Y

We build the container again using the docker build command:

docker build –t mycontainerizedwebsite .

This now finally results in our web application in a container that we can then run on any windows server that has windows containers enabled.

Running the website in the container

In order to test if we succeeded we now issue the docker run command and then map the container port 80 to a port on our host. This can be done by using the –p option, where you specify a source and destination port. We also need to specify a command that ensures the container keeps running. For this we now use e.g. a command like ping –t which will result in an endless ping loop, that is enough to keep the container running. so to test the container we now run the following command:

docker run –p 80:80 mycontainerizedwebsite ping localhost -t

Now we can browse to the website. Be aware that you can only reach the container from the outside, so if you would browse to localhost, which results in the 127.0.0.0 you will not see any results. You need to address your machine on its actual hostname or outside IP address.

Summary

To summarize what we have done, we first created a docker image capable of running IIS, then we added ASP.NET 4.5, then we added webdeploy and finally we deployed our website to the container using webdeploy and the package generated by Visual Studio.

In the next post I will show you how we can use this image in build and release management using VSTS and then deploy the container to a server so we can run automated tests as a stage in the delivery pipeline.

At the moment of writing you can not use the standard Visual studio tests task to run your xUnit unit tests on DotNetCore 1.0 and then publish the results to VSTS.

You need some different steps to get DotnetCore compiled and run your unit tests in a VSTS build. Here are the steps to make it work:

Pick the standard Visual studio template for your build:

In this default build workflow first add a command line to run a dotnet restore command so your build of your solution will succeed. do this right after the nuget restore step:

In the command line options set the tool to : dotnet and the command line argument to: restore

Now our solution should build.  The next step is to replace the Test assemblies task since in dotnet core you run your unit tests also using the dotnet command line. So we replace this task with a new command line task and provide it the following arguments:

test $(Build.Repository.LocalPath)<locationoftestproject> –no-build -xml testresults.xml

Of course here you replace <locationoftestproject> with the correct location of the project containing your unit tests. In my case I was using the MVC music store sample project (which can be found here: https://github.com/aspnet/MusicStore )and for this I needed to replace the test location to: testMusicStore.Test

Note that the additional arguments instruct the framework not to build the solution again, since we already have done this and would be a waste of time. The –xml option provides the name of the xml test results file that we want as output so we can publish the results to VSTS.

Now we have run the tests, so the final step is to publish the results to VSTS. For this we use the Publish test results task

And for this task we need to provide the name of the file it needs to publish. this is of course the name of the file we specified as the –xml output. We also need to specify that the results file contains test results in the xUnit format. Default it is set to use the JUnit format. But this is a simple select from the dropdown test Result Format.

So the final settings for the Publish task should look like this:

Now we can run our build and you will see the following results appear:

As you can see our tests are run and nicely reported. In this screenshot I switched to the tests tab in the results views that are available for a build and changed the outcome to show all results. Here you can see all de details of every test you have, when they have started failing, and how long they run.

As you can see all integrates nicely, only not with our default Visual Studio test task. I assume we might see this integrated in the future when we get new releases of the build tools for DotNet Core, but for now this is a pretty nice and clean solution to get things up and running.

Enjoy!

Marcel

I was just doing my work on windows 10 and for no apparent reason the windows 10 start menu would not respond anymore to either my Windows hotkey on the keyboard or by clicking on the start menu icon in the left bottom corner. This meant no response to the windows key and me typing the application I wanted to start, not being able to shut down my machine, etc. So this gave me some real headaches because the only way I could solve this is do a reset of my PC or just repaving my machine and install windows 10 again.

This has happen to me several times and most of the time after I had been doing some Mobile App development where I build mobile apps that are cross platform. Lately I had to do this for my talk at VS Live in Las Vegas and for that I had to turn on developer mode on my windows 10 machine.

Now I am not sure if his issue is caused by the mobile development I have done or if it is just my SSD drive acting up on me and corrupting certain files on my system. I do know that running the following powers shell command (started in administrator mode of course) solved the problem form me:

Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)AppXManifest.xml"}

The option DisableDevelopmentMode does the following:

Registers an existing app package (.appx) installation that has been disabled, didn’t register, or has become corrupted. Use DisableDevelopmentMode to specify that the manifest is from an existing installation and not from a collection of files in development mode.

At least this was a way to solve it for me and hopefully it will work for you as well.