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.
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.