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.

I have been hitting an issue with MVC4 Web Api where my global error handling filters were not executed. The only advice out there is that they will not execute if the action throws an HttpResponseException.

I have finally figured out that returning a lazy IEnumerable instance will also cause the global error handler to not execute. In fact, it won’t cause controller or action level exception filters to execute either.

Looks like a lot of people hit this issue and come up with lots of “interesting” solutions to get this to work. The answer is surprisingly simple however.

Assume that the controller action is like the following:

I have a web role (RP) running in Windows Azure that uses ACS 2.0 as the identity provider (IP). The web role is configured with a certificate to work with the authentication negotiation and subsequent security session. The certificate supports both domain.com and www.domain.com. The issue is that the federation authentication configuration of the web role can only specify one realm and the realm attribute is a required value.

I tried to install the New Relic Nuget package for an Azure solution. Unfortunately the Nuget install script failed to update the ServiceDefinition.csdef file and provided the following error.

Unable to find the ServiceDefinition.csdef file in your solution, please make sure your solution contains an Azure deployment project and try again.

One of the good things about Nuget is that the install scripts are easily available to the solution.

Sometimes things go wrong. For example, when files are not on your local disk when you expect them to be. I see this pop up every now and then when working in a team environment or even as a single develop across multiple machines. Usually it is because something has not be submitted into source control. Maybe the file was never bound to source control in the first place. I have seen Visual Studio simply miss files as well.

Normally this is not a problem. The compiler will complain if a C# class file is missing because it can’t do its job. Unfortunately a Web project does not throw a compiler error when a content file is missing. Thankfully there is an easy fix.

I’ve been having issues running deployment tasks in a TFS build today. The batch file I’m getting it to execute on a target machine just doesn’t seem to find the setup packages in the TFS drop location. I suspected that it was executing the deployment steps using a local account on the target machine. Adding an echo %username% in the script confirmed that this was the case. Even though the target machine is a domain joined machine, local accounts won’t help with getting access to the TFS drop location which is secured by an ACL.

The account used to execute a deployment step is the lab agent service account identity on the target machine.

By default this appears to be local system. You need to reconfigure the local Lab Agent service on the target machine in order to have it execute deployment steps under that account.

The deployment step now identifies that it is executing under the correct credential.

I still get a deployment step failure, but weirdly the deployment and the build were both successful.

I’m trying to get out for a ride a couple of times a week. Yesterdays ride was a bit of misadventure though. At the 3km mark, I got a puncture. Do I turn back and cut my losses or keep going up the mountain on the spare to have fun on the downhill track? Hey, I have a spare and a repair kit. Up the hill we go.

I then get a second puncture 100m from the top of the mountain.

We encountered a couple of issues yesterday when updating TFS 2012 from RTM to Update 1. The installation went well on the application tier and the data tier. The upgrade for the build service hit some problems.

The event log on the application tier contains the following error:

Operand type clash: dbo.typ_BuildControllerTableV2 is incompatible with dbo.typ_BuildControllerTable (type SqlException)

With some quick escalation by Grant, our issues were resolved this morning. Grant has posted about it here.

The only other issue we seem to have hit is that exposing TFS over HTTPS was broken after the install. Brian Harry indicated this would be the case but did not elaborate on the details. It seems like the installation package for Update 1 has reset the IIS configuration back to its default TFS install. The affect of this is that the https binding was removed from the site. Simply adding this back in has restored our external TFS connectivity.