Global.asax Session_Start code not running

We were moving an ASP.NET 2.0 application from IIS 6 to IIS 7 and we ran into a problem. The code in the global.asax Session_Start was not running. However, this code had been running fine in every environment (development, testing, production) in IIS 6. Through a lot of research and trial and error, we figured out a solution to the problem. I’m not sure the problem was necessarily with IIS 7 because we saw posts on the Internet of the same symptoms on IIS 6.0. It should be noted that when the code is executed within VS, it ran fine too.

Our standard has been to use the Web Deployment Project for creating the compiled output that is then copied to a IIS server. Our standard has also been to merge all outputs to a single assembly. When this is done, all compiled code is put into a single DLL. If you use the global.asax, there is file called App_global.asax.compiled that is used to tell the runtime engine to reference the single DLL for the global.asax code. It would appear that when you have your project compiled into a single DLL, this problem manifests itself.

Our solution was to change the way the code was to be compiled. Rather than merging all outputs to a single assembly, we set it to merge all pages and control outputs to a single assembly. Do so still creates the App_global.asax.compiled file, but instead the compilation of the global.asax code is into its own DLL (App_global.asax.dll). By doing this the code in the global.asax started working.

Job hangs when running SSIS package

I had a SSIS package that I modified and put out onto a development server. When I ran the existing job, the job would hang. Based on troubleshooting, it would appear the package would not even begin to start. When the package was executed from the development PC, it ran fine. When remoted into the SQL Server and ran the package in BIDS, it ran fine. However, when we ran in a command line the command that was in the job step, it would produce the following error. Note that the package would in fact run though under this method.

The file name is not valid. The file name is a device or contains invalid characters.

It turns out the problem was the fact that the package used a configuration file and the config file specified the location of where the checkpoint file should be written. The config file on the server had the checkpoint file location as the developer’s workstation and not of the location for the development environment. Upon changing the config file, the job would then run the package successfully. It would appear that when this type of error is encounter in a job, the job would hang and not handle the exception correctly.