Feedback
Peter, good to hear from you.
Yes, I know about the problem on 1.x sites. We got bit by it. It is a very interesting problem in version 2.0 because the project migration wizard put the global.asax.cs file in the app_code directory. I figured it would know it no longer needed the code behind file.
We did some work with Microsoft and Scott Guthrie's team on the Project Migration Wizard prior to the VS 2005 release and we experienced a bunch of bugs that were fixed but not this one. I guess I should send something off to Scott to let him know this one still exists.
It was your post on the ASP.NET forums that put us on the track to find the solution to this problem.
I'm not sure it this is the same problem but I am using a global.asax file to declare some server side objects using the tag and everything works fine in the development environment. When I deploy or publish the website however the global.asax appears to get compiled and put into the bin folder as App_global.asax.dll. I assume this is just the "code" part of the file and the definitions get lost since I get the error "Object reference not set to an instance of an object." when I try to access the objects in the ASP.global_asax.Session_Start. If I copy the global.asax with the tags to the production web site it seems to work fine. This appears to be a bug with the deploy.
Jon,
This appears to be similar to what I have encountered. A couple questions:
1. Is your application running under .NET 2.0?
2. If yes, did you upgrade the application from .NET 1.x?
3. Does your Global.asax have a code-behind, Global.asax.cs(vb) assocated with it?
We saw this same behavior in our upgraded application from 1.1 to 2.0. I am not sure if it's the converting utility or not but I think it is. I know Microsoft has upgraded it several times.
The real solution for us was to get rid or the global.asax code-behind file and bring all of our code in-line to the .asax file and all worked well, both in development and in production.
I've noticed the same problem when converting VB.net web projects from 2003 to 2005. I've noticed however, that the Global class (defined within Global.asax.cs) doesn't get compiled into the assembly (verified by using Reflector post-build) when the class is embedded within a Namespace block. When I don't wrap it up in a Namespace block - the class exists in the build output!
Thank you for the reply. Yes, this makes perfect sense, the team working on ASP.NET is one in the same and the design of how the conversion work was the same.
So wrapping it up in the namespace takes care for the issue for you going forward?
Sorry about that post - I think I responded prematurely. It turned out that it was a namespace behavior in VB.net that I was not aware of. If you have a root namespace defined for the assembly (eg Root.Namespace) and you declare a namespace in one of your code files such as:
Namespace Root.Namespace.SubNs
Public Class Test
End Class
End Namespace
The Test class will be compiled as: Root.Namespace.Root.Namespace.SubNs.Test, and not as Root.Namespace.SubNs.Test, like I had expected. It appears that VB.net's compiler behaves differently than c#.
Ah, great to know. I was under the impression the source of this problem was very similar to mine and caused from the VS 2003 -> VS 2005 conversion. The behavior you described was identical.
Thanks for the update.
We package the site in an installation package (msi) file. We've the application_start not firing problem when the package is installed on production server. The package runs fine on QA and dev server. We use the Web Deployment project to pre-compile to a single assembly. The QA and production server has the same configuration: Windows 2000 server, IIS 5.0, .Net 2.0 framework. We have a code-behind file for Global.asax. The output of the Web Deployment product does not contain Global.asax because it's compiled into the single assembly. The marker file bin\App_Global.asax.compiled points to the correct assembly (see http://www.velocityreviews.com/forums/t300292-web-deployment-projects-globalasax-problem.html).
Finally we found the problem: We use the ReportViewer control and the ReportViewer Redistribute 2005 is not installed on the production server.
Hint of the cause of the problem comes when we copy the source code to a virtual directory on the production server. When we try to bring up a page, we got an error saying it can't find the ReportViewer assembly referenced in the web.config file.
@Jon Pierson
Hi Jon, im encountering the exact same problem as you did. How did you go about fixing it to make it work in the production server. My applcation runs perfectly on my local machine but after i deployed it using the Publish Website feature. The objects i defined in the Global file are all complaining about "Object reference not set to ......"
Help Help!!
Regards
Jin
My solution:
I downloaded an update / plugin for Visual Studio from that allowed me to develop a “Web Project” just like I would be develop a “Windows Project”. This type of project is completely different from the “Web Site” technology that comes with Visual Studio ‘out of the box’ when you first purchase it. I think the plugin is called something like: "Web Deployment Projects Plugin for VS2005”. – I can try to source out where I got the files again if you have trouble finding it. You will know you have this feature installed when you can perform: File -> New -> Project -> ASP.NET Web Application
After that update was installed, I installed a second addition / plugin to my Visual Studio that allowed me to convert all of my project files to a “Web Application”. – This is an important step for the project’s success. You know you have this plugin installed when you can right click on the solution in your solution explorer and select “Convert to Web Application”. If you do not have this plugin installed, you will not see this option.
After that step was complete, my web project actually resembled more of a windows application then a .net website. I now have for example:
Default.aspx,
Default.aspx.cs
and Default.aspx.designer.cs.
Also, now all of the “inherits” attributes work as they are supposed to in a web application. Before now you could have had many aspx files ‘inherit’ the same code behind because the compiler was not really compiling this attribute properly.
Before this step, the inherits attribute was there but was not built into the solution correctly. If this is unclear, I can explain this in another posting.
Ok now that you have created a ASP.NET Web Application, Copied all of your old site content files to your solution explorer, converted your new application to a Web Application, you may have a lot of build errors because the application will compile your project more strictly then it used to. If you get no build errors, congratulations on proper web application design.
Ok. Now about the global.asax compile issues:
When this new type of project builds, the code behind of the global.asax file gets built right into the dll for the solution so there is no need to mess with global.asax compile issues, file placement, ‘flat’ architecture or any of that jazz. In fact I still have my global.asax code running as a code behind quite successfully.
Simply upload your new project to your new server either by publishing or copying your development file, not forgetting any differences you might need in your web-config for your production server (SQL connection strings etc.) and your site should work fine.
I am behind on my project now, so I must get back to work. If you need to contact me for any reason, you can do so through one of my websites:
www.thebestofalltime.com
www.thechristiannewsnetwork.com
Good luck everyone!
Wow Damian, great comment. I think you have a couple tools I didn't have when I faced these issues.
I am aware of the first tool for Web Project but I am not aware of the tool that will Convert to a Web Application. I think you found a nice solution to these type of problems.
If you can find links to these tools please comment again so I can post a follow-up to my original post.
Thanks.
There is a strange behavior of the application_start event on windows 2003 based server. On that server the application_start method is executing every time while user send a request (means session started). Same build is working properly on XP based box.
On windows 2003 server I have IIS 6.0 while XP box have IIS 5.1. So what will be the problem ?
Is there any specific thing I need to take care means special configuration like session state, identity etc.?
Please let me know if anything required for clarification?
how to create Application_Start
function in asp.net send answer to
anirudhakumar.gupta@gmail.com
Thanks,
Im always confused...

#1
Peter Blum
03.07.2006 @ 10:16 AM
Cool info, Rob. A similar problem exists on ASP.NET 1.x sites. Users forget to copy the Global.asax file to the production server and find Application_Start does not fire. You would think that since they used the code behind file (Global.asax.cs or Global.asax.vb), the compiled code was already in the web application's assembly file. So the Global.asax file isn't needed.
However, it is needed. Nothing in the class "Global" will run without the presence of the Global.asax file.
So the next time your Application_Start method isn't running, make sure you copy the Global.asax file to the web app with the problem.