I am working on a project in which we converted an existing Visual Studio 2003 C# web application to Visual Studio 2005. I can and probably post a series of entries on all of the issues we faced converting this project but that is for another time.
The converted application has been running fine on our development systems pretty well since the conversion occurred. We recently put together some build scripts so we could get our build machine into action. Our build system integrates to our Sourcegear Vault repository, gets the latest code builds from the command line and deploys to a staging server.
We got the kinks worked out of our build and deploy process and decided to start testing the application on our staging server. The application fired up and we were able to login without any problems but when going to a page that had controls from Peterblum.com the page would not render and complained about the location of the license files. If any of you have not used the Peter Blum controls they are great controls and Peter offers great support. The only real drawback to them is getting the right files in the right directory and setting a license property on the controls to get his licensing scheme to work. It is a pretty straight-forward task if you do it all the time but we install and forget about it.
I went back through the Peter Blum documentation (very good by the way) and tried to see if something was missing in our deployment scripts that would put the license files in the wrong location. This checked out Ok. After a careful debugging session we determined what was happening.
In order to properly setup Peter Blum controls you need to set a license key propery on the controls we are using. This can be done in the Application_Start of the global.asax OR in a place like the Page_load of every page using the controls. The obvious place to set this key is in the Application_Start if you are using these controls in more than one form. This is how we have our configuration.
In this configuration our application works fine on our Windows XP development systems but when deployed to a Windows 2003 server running IIS 6 the Application_Start fails to fire. What? You may ask. Yes, it’s true the event we need to fire is not firing.
Since we don’t have any real way to debug such a problem on the staging system I changed the place the license key was being set, the Page_Load event. Upon doing this the form loaded fine and the Peter Blum controls worked as before. How can this be happening is the question I had.
It turns out that the problems starts in our .NET 1.1 version of the application and how 1.1 handled the global.asax. This file has a code-behind page named global.asax.cs and all the code you would use for global events such as the Application_Start would be setup in there. This is how we setup ours.
As I mentioned, we used the conversion tool in Visual Studio 2005 to convert our web application to .NET 2.0 this way. The conversion ran fine but put the global.asax.cs file in the new App_code directory. This is a bad thing, for some reason the conversion thought it needed to be in there and on development it worked fine so we left it in there. All things pointed to this as the problem. We took the code in the global.asax.cs file and put it in the global.asax removing the gloabal.asax.cs file from our project and re-ran the build scripts, tested and all was good. The Application_Start fired once again.
As of ASP.NET 2.0 the global.asax is only one file with no code-behind.
I don’t know why the project ever worked as it was but this fixed the problem. Apparently there is a bug in the VS 2005 web application conversion tool that Microsoft should take a look at.
Technorati Tags: ASP.NET, C#, Microsoft, Visual Studio