Learn from my mistakes, you don't have time to make them yourself

I posted back in 2010 about how to get WiX to correctly deploy a website using harvesting. It was a rather clunky solution that required changes to your development machine (and the same for everyone in your team) as well as any build infrastructure you are running. I have now discovered a much cleaner solution using harvest transforms (tested using WiX 3.7).

As a recap, harvesting pulls files from the project reference compilation into the MSI and puts them into a single output directory. This means that website content and the binaries will be in the root folder of the deployment. This is no good for websites that require binaries to be placed into a bin folder.

I’ve previously posted about Nuget package update pain with the NewRelic Azure package (here and here). I’ve had issues again when updating to the latest version. This time I’ve added in a Worker role and found that the PowerShell script that installs the package did not configure the Worker role. I have gone through the PowerShell scripts to manually ensure that the configuration files match what they should be.

One of my favourite development packages to use over the last year has been a micro-ORM called Insight.Database written by Jon Wagner. Version 2.1 of this excellent package comes with automatic interface implementations so you don’t even have to write DAL classes anymore.

I haven’t been able to play with this feature until the last week. One of the roadblocks was that I use Unity as my IoC for dependency injection which does not natively support injecting these types of instances. What I need is to be able to configure a Unity container to return an auto-implemented interface in a constructor. I have created Unity extensions before for injecting ConnectionStringSettings, AppSettings and RealProxy implementations so creating one for Insight.Database should be simple. The RealProxy Unity extension was very similar to what I need as the logic is just about the same.

I am using the timezoneJS to provide time zone support for JavaScript running in an MVC4 website that is hosted in Azure. The JavaScript library is bundled with 38 zone files under a tz directory. My understanding is the library reads these zone files in order to correctly determine time zone offsets for combinations of geographical locations and dates.

The library downloads zone files from the web server as it requires. The big thing to note about the zone files are that they are really heavily commented using a # character as the comment marker. The 38 zone files in the package amount to 673kb of data with the file “northamerica” being the largest at 137kb. This drops down to 232kb and 36kb respectively if comments and blank lines are striped. That’s a lot of unnecessary bandwidth being consumed. MVC4 does not understand these files so none of the OOTB bundling strip the comments. The bundling support in MVC4 (via the Microsoft.Web.Optimization package) will however allow us to strip this down to the bare data with a custom IBundleBuilder (my third custom bundler – see here and here for the others).

I have an ASP.Net MVC4 website that is running passive federation to Azure ACS. This works great for standard http requests from a browser. I have now added some web api services to the same solution but hit issues with acceptance testing.

I previously posted about issues I found when updating to the latest Azure NuGet package published by NewRelic. Unfortunately the install PowerShell script for the latest package now has more issues than the previous version. Here are the issues I found and how to fix them.

Visual Studio has a great feature for web.config files where XML transformations can be done based on the current configuration. This is typically actioned when the web application is published. Unfortunately the MSBuild scripts only cater for web.config. This is a problem when you start to break up your configuration into multiple files and link them back using the configSource attribute.

I’ve been wondering about this for a long time. None of the reading that I’ve done has conclusively answered this question. It just so happens that I’ve been developing in a VM for the last couple of months. I got the chance tonight to downgrade the VM specs to a single core to run some tests. The results were very pleasing, yet completely unexpected.

I’m working on an MVC project which pulls in lots of Nuget packages. Font Awesome was the latest package but there is a discrepancy in the locations for the font files between the css url references and the location that the Nuget package uses for the MVC project. The css files use a reference to font/ relative to the current resource. The Nuget package puts all the resources into Content/font/.

I don’t want to change either the css file from the Nuget package or the location of the fonts used by the Nuget package. Doing so will just cause upgrade pain when a new version of Font Awesome gets released to Nuget.

I looked at custom routing options but these just seemed to cause more problems than they solved. It then dawned on me that I could use an IBundleBuilder implementation now that I know how they work.

Recently the bundling and minification support in ASP.Net MVC4 have been causing grief with JavaScript’s having unexpected tokens. The minification process is failing to process the bundle of scripts correctly, although it does kindly add a failure message to the top of the bundle output.