ASP.NET MVC always throws a System.Globalization.CultureNotFoundException

I ran into this problem today.

Being an overly pedantic developer, I was annoyed that my ASP.NET MVC project was always silently throwing this exception on startup.  So I dug into the guts of System.Web.dll to find out ‘why’ this exception was being thrown.

It turns out that upon startup, ASP.NET tries to create the CultureInfo for the project by looking for the good old Satellite directories… so far, so good, this makes total sense.

The issue is more about HOW this is done.

The System.Web.Compilation.StandardDiskBuildResultCache class calls its internal FindSatelliteDirectories method.

This, in turn, fetches all the folders (a.k.a. Directories) that it finds in the Temporary ASP.NET files temp folder, and iterates over them to see if any of them are Satellite Directories.

There is a conditional statement to bypass this check if the folder is called ‘assembly’ or ‘hash’, yet it fails to check if the folder is called ‘UserCache’, which also definitely not a satellite folder.

Personally I think this is bad design in the first place, since:

  1. Satellite folders have a predictable naming convention
  2. Why check for what it is not rather than what it is?
  3. What happens if the developer decides to throw in another 5 folders? This would be an extra 5 exceptions being thrown… and nobody likes the computational cost of exceptions.

I really wish Microsoft would fix this… until then, we’re going to have to live with seeing a bunch of ‘System.Globalization.CultureNotFoundException’ on startup :(

Note: the System.Web.dll that I am checking is v4, and the one that comes with .NET Framework v4.5



Method not found: ‘Boolean MS.Internal.AssemblyHelper. IsXLinqNonIdempotentProperty’

If you are using .NET 4, and run into this exception:

Method not found: ‘Boolean MS.Internal.AssemblyHelper.IsXLinqNonIdempotentProperty’

Then it turns out that there is actually a bug in .NET 4, which seems to occur when you apply a ScaleTransform to an element that has nested templates (which is almost always the case in most LOB applications).

Turns out that the good folks at Microsoft have addressed this issue in December 2010, by releasing patch number KB2464222 which you can grab here :)