Through the life of this blog in its many guises I have used Blogger, Community Server and WordPress. Now comes the time to move again and I have opted to use MiniBlog; a project created by Mads Kristensen of Visual Studio Web Essentials fame.

About MiniBlog

MiniBlog is written in ASP.Net, C# and uses the website template in Visual Studio. It has a simple architecture and persists the blog posts in XML format as physical files on the web server drive. There is much more to this platform though such as:-

  • Windows Live Writer support
  • RSS and ATOM feeds
  • Support for robots.txt and sitemap.xml
  • Much much more…

Why move?

Although I have had a great experience using WordPress over the past few years, I have become more apparent of the bloat that is downloaded to the users browser in the form of Java Script and CSS. As a developer who strives to optimise web pages to get a better UX for the user, this didn't sit right with me.


This is the old sites Java Script showing over kb of data downloaded to the users browser.


The CSS is also loaded with the many styles from various plugins used in WordPress.

Wordpress is written in PHP and my experience is .Net, also the back end it's MySQL again a technology I am not 100% experienced with. So to make the changes to optimise the blog to a level I was happy with would leave me with either rewriting the entire theme and persistence layer or move to a technology stack I can have more control over. MiniBlog gives me this. I can create the style and layout I want with Razor and CSS and tweak the caching layer in the C# code. I can also get gulp up and running to run tasks to concatenate and minimize the css and Java Script files. Also like other projects I am working on, I can easily create a work flow in Team City to do the build and deploy.

What I had to do

Firstly I had to export all my blog posts from WordPress into a format that MiniBlog can understand. Again thanks to Mads Kristensen I could use the MiniBlogFormatter tool to get my posts into the correct format. This tool outputs each post to a seperate XML file. Then going through the current blog I found and separated post I wanted to keep that covered topics and technology that are still current. Then I created a temporary website in IIS to test these posts. It soon became apparent that the directory structure was different and MiniBlog uses a post directory to store files. I didn't want to loose any links to popular posts especially those that are referred to from other sites, so I created a url rewrite rule to do redirects to the new structure for users coming in on the old url.


As I have mentioned in a past post concatinating and minification of Java Script and CSS can be achieved by using gulp. Once this was done, the number of files downloaded was much less than before.


Now only 16 files are downloaded as opposed to 46 in the old site.


Also with the CSS, there are only 2 as opposed to 7 requests.

With the images, I used Paint.Net to decrease the resolution and size for better performance.

Then in IIS, I navigated to the HTTP Response Headers section for the directories that contain the Java Script and CSS files.


Clicked on the ‘Set common headers’ link in the top right hand corner.


Set the expires date to a date far into the future.


I was getting a lot of spam comments which Akismet took care of, so I had to find an alternative which would also protect me. I enjoy reading the comments and like to respond so switching off comments was not an option. I eventually went for Disqus which has a plugin architecture that was really simple to implement.

So there you have it, this is now the new blog site. It will change in style over the next few weeks as I make tweaks here and there, but with the CI/CD workflow I have in place this is very easy to work with.

What next?

I run all my sites of the same box which also has both MySQL and SQL Server running on it, so soon I can switch off MySQL, uninstall the PHP processor that it's part of IIS and hopefully free up some more resources.

Happy coding

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