A few years ago I posted about some recommended reading for developers. The tooling I use has changed ever so slightly (NSubstitute replaces RhinoMocks) but the content is still completely relevant. More recently I provide my team with recommended reading specifically about async development.

I’ve been working on a side project that works with HTML responses from websites when I hit an issue when authenticating to a development STS that uses WIF. I found that WIF uses HttpUtility.HtmlAttributeEncode to dynamically generate a form that contains auth information in a hidden field. The auth information is XML but the form does not get processed correctly by some custom code because the HTML is invalid.

So my debugging efforts seem to have uncovered an issue in HttpUtility.HtmlAttributeEncode (or more specifically the HttpEncoder class).

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 have secured my api action using the following.

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.