Nasty ASP.NET 2.0 Bug...Postponed?


I've been working on some ASP.NET 2.0 code for the last few weeks and ran into a bug that (in my opinion) is particularly nasty.  If you are comfortable with the 1.x model at all, you're likely to run into it.  In the 1.x model, all code-behind classes were compiled into a single assembly.  So you could:

MyCodeBehindClass ctrl = (MyCodeBehindClass) LoadControl("...");

In the 2.0 model, each page/control is compiled into its own assembly!  so your LoadControl doesn't know about unless you move the codebehind into a further class in the AppCode section of your website. 

Here's a response from MS in the ASP.NET forums:  Also, the URL link above is the actually lady bug that they've marked as Postponed!

This seems like such a hack and is making me wish more and more for a 1.x compatibility mode.  I know of several users who are running into this with migrated projects, but it happens in 2.0 projects all the time (and the errors produced are not helpful in figuring out what went wrong).

So ASP.NET team, please tell us why this is a better model?  Please don't tell me its because you wanted to appease the ASP people in letting them drop new aspx files into fileshares.  While this is laudable, it should not be the default behavior.  It makes no sense in most large-scale web projects. 

Shawn Wildermuth
Author, Teacher, and Coach

My Courses

Wilder Minds Training
Vue.js by Example (New Lower Price)
Bootstrap 4 by Example (New Lower Price)
Intro to Font Awesome 5 (Free Course)
Building an API with ASP.NET Core (New Course)
Building a Web App with ASP.NET Core, MVC6, EF Core, Bootstrap and Angular (updated for 2.2)
Less: Getting Started (New)
Using Visual Studio Code for ASP.NET Core Projects
Implementing ASP.NET Web API

Application Name WilderBlog Environment Name Production
Application Ver v4.0.30319 Runtime Framework x86
App Path D:\home\site\wwwroot\ Runtime Version .NET Core 4.6.27817.01
Operating System Microsoft Windows 10.0.14393 Runtime Arch X86