These are initial rumblings resulting from my ASP.NET 2.0 shellshock in attempting to migrate a reasonably sized ASP.NET 1.1 project to ASP.NET 2.0. The thesis of my rumblings is that the ASP.NET 2.0 development model is far more different than ASP.NET 1.1 and requiring a much greater investment in migration and adoption than we were led to believe.
...Or maybe I'm just pissed that migrating my 1.1 app to work in VS2005 is a helluva lot harder than I thought it'd be.
Here are just a few of the rumble bits I'm chewing on at the moment.
- From a MSDN ASP.NET migration reference. The code inline model is now the default model for Visual Studio 2005. Code-behind classes become partial classes. They "expand" the .ASPX page in 2.0. In 1.1, the ASPX pages inherited from the code-behind classes. In ASP.NET 2.0, a partial class is particularly useful for code-behind files, as it removes the inheritance relationship that is present with the older code behind model.
That's a rather significant change, seems to me, particularly how it impacts migration. Think of all of those "The type 'this code-behind class' already contains a definition for txtName" for starters.
- From a MSDN conversions issues reference. The new ASP.NET 2.0 compilation model uses multiple assemblies that are normally dynamically compiled on the server. This model improves both Web site performance and updatability. However, if your ASP.NET 1.x code-behind files reference another code-behind file, then you will have a broken reference because the referenced code-behind file will no longer be in the same assembly. The solution is to create an abstract base class in the App_Code folder to reference at compile time, which will load the actual class from the page assembly at run time. As in
App_Code\Stub_Control1.cs
abstract class Control1 : System.Web.UI.UserControl {
public static string myName = "Control1";
abstract public void foo();
}
THAT sucks.
- From some other MSDN page. "Most Web applications require one or more support classes. In ASP.NET, the preferred method was to create a separate project for support classes and then add a reference to the support project within your Web application. Even if you didn't create a separate project, you still had to create a reference to whatever namespace you used within your own application. Although having a separate project made sense for larger and more complicated applications, it was often painful for developers who only needed one or two simple classes. ASP.NET 2.0 introduces a new way of adding support code, the /code directory..."
So I shouldn't be thinking in multiple projects. Namespaces are painful to use?
All I know at the moment is that life was good when I could inherit a webpage from a basepage class and pass both ASP.NET controls and my usercontrols up to the derived pages. Now I've got some damned abstract Stub_MyPage_aspx_cs.cs in an \app_code directory telling me my basepage class doesn't exist and null reference errors on ASP.NET web control instances thrown from my base class.
I remain confident that life with ASP.NET will be good again. Right now I'm just not feeling the joy.