So after finally migrating to Web Site projects and deploying my site to the production server things seem to work fine.
But I noticed dates like '13 Dezember 2006' were showing up on my pages, what's that all about? The production server has a German OS, that's why I have the following code in Global.asax.cs
protected void Application_BeginRequest(Object sender, EventArgs e)
{
System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB");
System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-GB");
}
This makes sure that whatever OS or user is running the app, the dates will always be in British format.
Why isn't this working anymore? It seems global.asax is not working correctly.
As far as I understand in the pre-compiled Web site projects you don't have a global.asax file in the root of your site anymore but instead a file called 'App_global.asax.compiled' in the bin directory. This was there alright.
When I copied global.asax back into the root I got the error that my Global class is defined in two places, once in the main precompiled assembly and secondly in a dynamic assembly for 'App_global.asax' and the runtime can't figure out which one to use.
The type 'ASP.global_asax' exists in both ...WebUI.DLL and ...8725\App_global.asax.ocwfm9jz.dll
So it seemed I can't have global.asax there but the runtime also doesn't fire 'bin/App_global.asax.compiled'!
I fired up Process Monitor (be carefull when running this on a production server, it slows things down) to have a look at the access to 'App_global.asax'. I set a filter 'Process Name is w3wp.exe' to limit the output. I couldn't see any references to 'App_global.asax' but saw that a file called 'PrecompiledApp.config' was not found. I remembered this file being created during the compilation of the site but my deployment script doesn't include it in the zip file that goes on to the server.
Well turns out, it has to be there. I copied it over and suddenly my dates worked. I guess the runtime looks for that file and only when it is found actually looks for the *.compiled files in /bin/.
UPDATE:
Once again I noticed German month names in some XLST output, again an indication that Global.asax is not firing. You can actually fix this by setting the cultures in web config:
<system.web>
<globalization uiculture="de" culture="de-DE">
<system.web>
But I do more stuff in global.asax, especially global error handling.
So I spend some hours figuring out why global.asax is not executing on the live server. It worked fine on staging and also for other applications on the server. It didn't throw any errors anywhere but just didn't execute all at. I couldn't find anything about this problem online and changing web sites and application pools didn't help either. There were also no problems accessing any of the files. While looking at the assemblies in Reflector to check whether all the classes are there I noticed that there was a reference to Microsoft.Web.Extension, I had just replaced ASP.NET Ajax Beta 2 with RC1 where they changed the assembly to System.Web.Extension. The bin directory on staging had both assemblies while the live site only had the new one. After removing the reference to Microsoft.Web.Extension and rebuilding the assembly, the site worked fine. I wonder why this didn't threw an error and the rest of the site worked but global.asax didn't.