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: http://forums.asp.net/928782/ShowPost.aspx#928782. 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.
|Using Visual Studio Code for ASP.NET Core Projects (new)|
|Implementing and Securing an API with ASP.NET Core (new)|
|Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS|
|Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)|
|Best Practices in ASP.NET: Entities, Validation, and View Models|
|Front-End Web Development Quick Start|
|Lessons from Real World .NET Code Reviews|
|Node.js for .NET Developers|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||220.127.116.11||Runtime Framework||.NETCoreApp,Version=v1.1|
|App Path||D:\home\site\wwwroot||Runtime Version||.NET Core 4.6.25211.01|
|Operating System||Microsoft Windows 6.2.9200||Runtime Arch||X86|