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. The Problem 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. The Solution 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
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.
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.
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.
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.
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.
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!
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?
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#.
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.
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.
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 binApp_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
@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:
http://www.thebestofalltime.com
http://www.thechristiannewsnetwork.com
Good luck everyone!
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:
http://www.thebestofalltime.com
http://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.
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?
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
[email protected]
how to create Application_Start
function in asp.net send answer to
[email protected]
Thanks,
Im always confused…
Thanks,
Im always confused…