Offline Web Applications

The HTML 5 specification, now available in most evergreen web browsers, gave the power of offline web applications. How this works is a manifest file is downloaded to the client which lists all files needed to make that page useable even if there is no network connection. This manifest file canm include JavaScript, CSS and HTML files. Of course it is possible to create an ASP.Net MVC application that can use this same technique as it renders HTML 5 anyway, however there are a few gotchas to look out for which I will cover in this post. Firstly the path to the .manifest file needs to be included in the HTML element at the top of the page.
<html lang="en" manifest="offline.manifest">
manifest file
For an MVC site, simply add the reference to the manifest in the _Layout file and add each resource you want in the browser application cache.
These resources above are used for the standard MVC template you get with Visual Studio 2015.
Now to get IIS to serve up this offline.manifest file you either have to add a mime type on the server or add it to the <system.webserver> element in web.config.
Its important that you add the clear element and you need then to add the usual types your site will serve up other wise you will get an HTTP 500 on each of these.
In Chrome when browsing to this page you can examine the Application Cache by going to the developer tools (F12) and going to the Resources tab.
Make sure that the 'Disable cache' check box is cleared as by default it is checked when you open up the developer tools and the browser will not retrieve the files needed from the cache.
Now by switching off your network connection or setting the Network throttling drop down to Offline (I disable my network card temporarily for a full test), your website should still view correctly and as the JavaScript has also been cached, it should function the same as well.
The main issue with the .manifest file is the browser does not know when the contents listed in it have changed unless the time stamp on the manifest itself has changed. One way to do this is to version the file and an even better way is to version it by using your application build number.
There are many issues with MVC serving up a .manifest file and the easiest solution I have found is to write out a physical file to the location the site is hosted in like this.
Which can be placed inside the Home/Index controller. Then add the path to the _Layout file like this.

<html lang="en" manifest="/Manifest/offline.manifest">

You will need to add write permissions to this directory for the IIS account so it can delete and write the file. Now if your build number increments each time you do a build and deploy, the manifest file will be regenerated and the client browser will pick up any changes.

Happy coding

Following on from the previous post where we already have a container that can run a static website inside IIS, this post will configure IIS to run a simple MVC website and deploy an application into it.

Setting up Containers for MVC Web Applications

So by calling Get-Container and Get-ContainerImage we should have our ServerCoreIIS container switched off and our 2 base images.


Firstly we are going to create a new container that will end up being our base image for MVC applications, so call the New-Container command like this:-

New-Container –Name ServerCoreIISForMvc –ContainerImageName ServerCoreIIS –SwitchName “DHCP”


Then start the container using the Start-Container ServerCoreIISForMvc command and enter a PowerShell session.
Once we are in the session, run ipconfig to see what the IP address is, then we can check that IIS is running by browsing to it.


Now we want to install all the features we need to run an MVC web site, which includes items such as .Net framework, so call this following command:-

Install-WindowsFeature Web-Default-Doc;Install-WindowsFeature Web-Dir-Browsing; Install-WindowsFeature Web-Http-Errors;Install-WindowsFeature Web-Static-Content; Install-WindowsFeature Web-Http-Logging;Install-WindowsFeature Web-Request-Monitor;Install-WindowsFeature Web-Stat-Compression;Install-WindowsFeature Web-Filtering;Install-WindowsFeature Web-Windows-Auth;Install-WindowsFeature Web-Net-Ext45;Install-WindowsFeature Web-Asp-Net45;Install-WindowsFeature Web-ISAPI-Ext;Install-WindowsFeature Web-ISAPI-Filter;Install-WindowsFeature Web-Metabase


That may take a while to run through.



When it is done you will be back at the PowerShell prompt and you shouldn’t need to reboot the container.
Exit out of the PowerShell session and stop the container. Now we need to create an image from this container, so call the Get-Container and pipe it to the New-ContainerImage command similar to what we did in the last post:-

Get-Container –Name ServerCoreIISForMvc | New-ContainerImage –Publisher AsteropeSystems –Name IISMvc –Version 1.0


Now you have an image of Server Core with IIS and MVC that you can create all future containers from.

Deploy an MVC application to a container

You may have a different method of how to deploy an application to a container, but for simplicity for this exercise I have a network share that I have copied an out of the box Visual Studio MVC application into. So create a new container from the IISMvc image.

New-Container –Name MvcSite1 –ContainerImageName IISMvc –SwitchName “DHCP”

Start it up and enter a PowerShell session and map a network drive like this:-

net use z: \\Server01\Share PASSWORD /user:USERNAME

Where you enter your network credentials for USERNAME and PASSWORD.

Now delete the default IIS website that resides in inetpub\wwwroot

Remove-Item C:\inetpub\wwwroot\iisstart.htm
Remove-Item C:\inetpub\wwwroot\iisstart.png
Remove-Item C:\inetpub\wwwroot\aspnet_client

Then recursively copy all files from the newly mapped Z drive to this location.

Get-ChildItem -Path Z: | % { Copy-Item $_.fullname C:\inetpub\wwwroot -Recurse -Force}


Get the containers IP address and browse to it and there it is, an MVC application running from a container.


So now you can quickly remove containers using the Remove-Container command and recreate a new container based off the IISMvc image as and when you need to.

Happy coding.

Creating an IIS Base Image for Containers

Now we have a base image from the last post, we can use it to create other images and containers. Enter a PowerShell command and call Get-ContainerImage, we should see our WindowsServerCore image.
For the sake of this demonstration we will let our containers get an IP address from DHCP in the network, other situations will lead to different DHCP configurations with the containers and their IP address as completely throw away.
So again in the host machine create a new VM switch, I have it mapped to my External switch which will handle the DHCP.

New-VMSwitch –Name DHCP –NetAdapterName Ethernet

Now we create a new container which will become our base IIS image, so call

New-Container –Name ServerCoreIIS –ContainerImageName WindowsServerCore –SwitchName “DHCP”

Then start it up with Start-Container –Name ServerCoreIIS
We will need to enable the IIS feature, so enter a PowerShell session.
Then invoke the command to install the Web Server feature.

Invoke-Command –ScriptBlock {Install-WindowsFeature Web-Server}

It will run through and should show an Exit Code of Success
Get the IP address.
We should see the typical IIS welcome page when we browse to it.
Now call Stop-Container ServerCoreIIS
We now need to create an image from that container, so call the Get-Container command and pipe it to the New-ContainerImage like this.

Get-Container –Name ServerCoreIIS | New-ContainerImage –Publisher YourCompany –Name ServerCoreIIS –Version 1.0

I have named both the container and image the same so I can easily determine the relationship.
When calling Get-ContainerImage we should see our 2 base images.
Now we can create any number of containers based off the ServerCoreIIS image like this.
Start one up, enter a PowerShell session using Enter-PSSession –ContainerName “IISWeb01” –RunAsAdministrator and get the IP address
We should then see the IIS welcome page again when we browse to that address.
So now we have a static website running from c:\inetpub\wwwroot on the container. In the next post I will configure the base IIS image to run an MVC website and create a container from that.

Happy coding.

Windows Server 2016 Containers

Containers, Docker and other similar technologies are such a trending topic these days I thought I would take the time to have a look at what all the fuss is about. Being a Windows developer and not completely happy with having to run VirtualBox just to get a Linux distro working so I can create a container, With Windows Server 2016 containers are built in so I wanted to explore them and see how it could change my development workflow. These posts are a journey of installing and configuring a set of containers to host an ASP.Net MVC website inside them. I initially tried running the PowerShell scripts linked by Microsoft on their ‘Windows Containers Quick Start’ pages, but I ended up getting so many errors with them (it is understandable as it is still in development) that I started from scratch and built the containers up myself.

Installing Windows Server Core and enabling the Container feature

Firstly get the Server 2016 ISO from Currently this is Technical Preview 4 and may change before the final release of Windows Server 2016.
I have renamed my ISO WindowsServerTP4 so I can find it on my machine much easier.
Create a VM and mount the ISO as the DVD drive.
Creating a Server 2016 Core Virtual Machine
Make sure the VM has access to an external switch.
I have called mine ContainerHost and will be a Server Core installation.
Start and connect to the Virtual Machine.
Follow the usual UELA and drive specifics.
Installing Server Core Installing Server Core Specify drive properties  
On first boot you need to change the password (use tab to move to the confirm password prompt).
Change password
Enter a PowerShell session.
Enter PowerShell session
Install the Container Windows feature by using the cmdlet
Install-WindowsFeature Containers.
Install Containers feature
Server will continue to install components during reboot.
Install and reboot
Login and renter back into PowerShell.
Now you can list all the command the Container feature exposes.
Run Get-Command –Module Containers
Container commands

Installing a Base OS Image

The main container features are now installed, however all containers must be based off an OS image and these come from OneGet. As Server Core Technical Preview 4 is version 10.0.10586.0, then the base OS image has to be the same. These images are WIM files and can be downloaded and saved to your local network from the Server Core Virtual Machine. First install the PackageProvider (OneGet).
Install-PackageProvider ContainerProvider –Force
Then you can use this to find container images from OneGet.
Find base OS images
Create a local share on your host machine and create a mapped drive in the Virtual Machine.
net use z: \\path-to-share\MyShare <account password> /user:"<username"
Save the WIM file to this share.
Save-ContainerImage -Name WindowsServerCore -Version 10.0.10586.0 -Destination "z:\WindowsServerCore.wim"
This will take a long time depending on your internet connection as it is Gigabytes in size.
Now the wim file is on your host network you can use the Install-ContainerOSImage to import it to your image collection. This way any time you want to create other Virtual Machines and run through this process again, you already have the WIM and don't need to download it again. However the WIM version will change if there is another Technical Preview or Release.
Install base OS image
Running the command Get-ContainerImage should list this as an OS image.
Display locally installed images
In the next post I will create an image that has IIS set up and then create containers based off this image.

Happy coding

In an older post on website performance using concatenating and minification I used the Ajax Minifier tool to do the work and used an MSBuild file to run that tool, now I use gulp which I find easier as it only needs a dependency on node and so can be separated out from the Visual Studio project itself and run outside the build cycle.


When run in a CI/CD environment, the gulp file is processed before an actual build takes place, this is so that the AssemblyInfo.cs file can be amended with the version information. The gulp file can be broken down into 3 main parts; the version, concatenation and minification and the assembly version writing.

The default task is run initially which will then run the version task. The version task reads any parameters passed into the gulp runner, in this case it is looking for buildVersion and uses the yargs library. If it is undefined, then it is being run outside the CI environment and can default to Then it performs the concatenation and minification of the styles using the gulp-concat and gulp-cssnano libraries. The resulting file is then written out to the public-assets/css directory which is where they are referenced from in the HTML view.The same process is taken for the JavaScript files except the gulp-uglify library is used to minify them.

Writing them to the public-assets/js and css directories allows the directories to be classed as static in IIS and so we can add addition headers such as expiry dates. Finally the same version number is passed to the assembly-info task which uses the gulp-dotnet-assembly-info library. This simply changes the AssemblyInfo.css file so when it is built, the assembly will have this version. Then when both JavaScript and css files are linked to in the HTML, the assembly version can be injected to the url.


TeamCity Integration

It is real easy to include a gulp task to TeamCity by creating a Build step to your pipeline and choosing the Command Line as the runner type.


Then specify ‘Custom script’ from the drop down and enter your normal gulp command in the Custom script text area.

With my gulp script I specify a build version parameter which gets its value from the environment variable BUILD_NUMBER. This is the counter that the gulp build step generates when it is running. I use this value, inject it into the gulp script using the version task which is then used to name the css and JavaScript files. It also changes the AssemblyInfo.cs file to create a unique assembly version.

Happy coding