My team has been cranking hard on our RTM milestone, and we are driving to hit our final ASP.NET + Visual Web Developer ZBB (Zero Bug Bounce) on June 3rd. Shortly after this we’ll enter lock-down and enter a phase where we’ll be responding to last minute bugs, customer reported issues, and driving long-haul stress results.
One of the things we’ve been doing the last few weeks has been getting customer applications upgraded to ASP.NET 2.0, and in identifying and fixing any compatibility issues we find. Compatibility is always one of those really hard problems that requires a lot of focus. One of the big challenges with server applications in particular is that it is hard to replicate customer applications within our lab (since every non-trivial web app has a database and usually requires a lot of work to setup). In addition to the deployment problems with getting customer applications working in our labs, there is also the bigger legal hurdle of getting permission to run and look at code in order to identify what a problem is when it is found.
In general we have seen three types of compatibility issues with ASP.NET 2.0 Beta2:
1) Deliberate model changes we made between versions to more optimize the web experience. Some specific examples of these are our move to be XHTML compliant by default at runtime, as well as the project and code-behind model changes we made between VS 2003 and VS 2005. These sometimes break existing code because they introduce new rules and semantics.
2) Bugs where we inadvertently changed the public defined behavior without meaning to. These are usually the most straight-forward to find and fix.
3) Subtle issues where a customer application was relying on the internal private implementation of an ASP.NET feature, instead of using just public APIs or documented behavior. These are the hardest to track down and the most interesting philosophically on what the appropriate way is to resolve (for example: if you changed code to fix a bug or make a performance optimization, but someone was inadvertently relying on the old behavior – do you back out the fix or not?). We spend a lot of time considering each of these on a case-by-case basis.
One of the big changes we are making for RTM is to further enhance the migration wizard in Visual Studio 2005 to help handle a number of the common cases that we’ve seen when upgrading applications with Beta2. In particular, we are spending time making sure that all of the model changes we made (item #1 above) are automated so that existing customer apps should for the most part “just work” without manual changes required. A few of the cases of model change behavior that we’ve seen that have required manual developer changes in Beta2 but should now be automatic for RTM when first opening the project and running the migration wizard include:
-- Classes and types stored in code-behind files that are utility classes shared across the project. In V1 all pages were compiled into a single assembly which enabled these classes to be directly referenced everywhere. In V2 we compile page UI into more granular assemblies to allow updates and avoid resetting applications when changes occur. With the RTM migration wizard we’ll now automatically move these utility classes under the App_Code directory (which is where shared code for the project now lives) so that they continues to work everywhere in the app (with B2 you need to manually move these).
-- Custom Page Base Classes that code-behind classes derive from that declare controls as field declarations. Because of the changes to the code-behind model, users who have migrated apps to V2 sometimes see null reference exceptions when accessing these fields on the “grandparent” base-class because the .aspx compiler can’t correctly wire-up the control references to the fields. We’ve now added support for this in V2, and the migration wizard will automatically configure code-behind classes that use custom base classes appropriately for you.
-- Referencing and then casting dynamically loaded user-controls or pages from non-code-behind classes. With Beta2 you can add a <%@ Reference %> directive to a page or user control to allow the page to dynamically load and cast these classes. What wasn’t available in Beta2 was the ability to load and cast these classes from non-code-behind code declared within the app_code directory. This broke some apps that used a pure MVC pattern or had non-UI utility classes that were directly accessing pages. We are updating the migration wizard to generate abstract class contracts in App_Code that will let these scenarios work with RTM without any developer changes required.
-- When upgrading existing web projects built with VS 2003 we’ll now set the XHTML config switch to off to maximize rendering and scripting compatibility (we saw a lot of people run into problems caused by the lack of a “name” attribute on the <form> tag for XHTML strict compliance). Note that it is just a configuration switch in your web.config file – so it is easy to switch to XHTML (either transitional or strict).
There are lots of smaller compatibility changes that we are then in the process of finding and fixing as well. As I mentioned above, one of the challenges with finding all these issues is getting lots and lots of different apps to upgrade to V2 and identify anything that we’ve missed or seems to have cause problems with the app. One of the ways you can help is if you have existing ASP.NET V1.1 applications, please try upgrading them to V2 and run through your tests to verify that everything still works. If you run into a problem, please enter a bug on the MSDN Feedback center (http://lab.msdn.microsoft.com/productfeedback/) with repro steps so that we can investigate and fix it.
We are also looking to work with a small group of volunteers in about a month’s time who have existing ASP.NET V1.1 applications and are interested in trying out the latest migration wizard and RTM bits to verify clean upgrades. If you are interested in being in this program, and can commit to running your existing V1 or V1.1 applications through our migration wizard and then verifying the functionality, please send me mail at: scottgu@microsoft.com. I’ll add your name to the list and we can then get back to you in about a month’s time with details on how to get and run a more recent drop.
ref: http://weblogs.asp.net/scottgu/archive/2005/05/11/406515.aspx