The more I play around with the new ASP.NET 2.0 code model the more I don’t like the way it works. The ASP.NET team claims that the V 1.x model was too complicated to use and aimed to make things simpler.
In doing so I think they’ve made it a lot harder to do more involved tasks and deal with page inheritance patterns that deal with more than a single page in the inheritance hierarchy.
I just took the West Wind Web Store and imported it into a VS.NET 2005 to see how it would go. The import basically takes your 1.1 project and makes some adjustments to all of the ASPX and source files and migrates them to the 2.0 CodeBeside Model using partial classes. For the most part this actually works pretty well, so you can get the benefit of the new functionality.
However, the upgrade process is not very complete. Specifically in my project there were a large number of pages that had controls showing up in source code that now no longer worked because ASP.NET now dynamically generates the control declaration. About half of my pages had to be fixed manually. No big deal that’s easy to fix.
However, I have a number of pages that are based on an inheritance structure that’s a bit complex. One of them is my MessageDisplay page which is called from a number of locations. The first problem I have with this is that the compiler did not catch an error in this class. Check out the following screen shot which was taking after compiling the Web site:
As you can see there’s an explicit error in the code, yet VS.NET is not showing me the error. Apparently ASP.NET compiles Global.asax fails because that code references this assembly and stops compiling.
I tried a manual compile of the page but that too failed. Because this page is a just a template for a base class page it’s very difficult to just run this page directly so I can’t even easily get ASP.NET’s error reporting to show me what the problem is.
After an hour of sleuthing and digging I finally figured out that the problem in global.asax is that even though my class is declared in a specific namespace (Westwind.WebStore), that namespace and class is not available from within dynamically compiled code that global.asax runs in.
One page class can no longer see other page classes even if they live in the same namespace! This is because they get generated into a dynamic namespace that is not accessible at designtime. Not sure what I mean? Open the Class viewer in your project and see for yourself. ASPX pages don’t show in the class veiwer either because they are not classes until dynamically compiled at runtime. This sucks, no?
The workaround is to go back to the 1.1x way, if you need to do something fancy. In my case with MessageDisplay I just move the page into the App_Code directory, removed the Partial Class moniker from the class, and removed the CodeFile attribute from the MessageDisplay.Aspx page. This basically makes the page behave just like ASP.NET 1.1. This means of course you have to deal with the issues that 1.1 had – namely you have to make sure you now manually define all controls your base class references because VS.NET won’t do it for you anymore. Again, this sucks.
Although this is probably not the most common scenario I’ve just described, once you get here you’re in for a lot of head scratching. The fact that the ASPX pages are virtual until runtime and are not visible is likely to break a lot of existing code and figuring out what is wrong is not trivial, because at that point you have to have a solid understanding how the page mechanism works.
(later…)
I’m still trying to figure out why the hell the ASP.NET compiler stops compiling and giving me a complete error list. I’ve now moved past the MessageDisplay issue, but I continue to find more pages where the project migration failed to remove all control references. Specifically it seems all forms that had a Form definition in their properties do not have that removed. IOW, I’m cleaning up a lot of Form1 references from my code behind classes. The damn thing is that the compiler finds one and stops reporting errors at that point. Not sure if that’s because the project is open as an HTTP project or what – it sure seems different than what I saw previously.
Aaahh. The complexity and different levels of all of this is ridiculous.
Anybody who was expecting a simpler tool in VS.NET 2005 will be in for a lot of pain <g>… It’s way more sophisticated in a lot of ways, but easier – no way…