3 comments
.NET 
Recently I did some tests migrating existing sites to ASP.NET 2.0. As it turns out, not all types of code will flawlessy upgrade, because of the new dynamic compilation model. When you have plain classes (not being code behind for ASPX or ASCX etc.), they will be put in the new App_Code directory.
However, in ASP.NET 1.1, all website code, including plain classes would be compiled to a single assembly. In the new model, multiple assemblies will be generated. So in cases where your plain classes need to reference a property or something on an ASCX or ASPX this breaks, because this would result in a circular reference between assemblies in .NET, which is officially not possible.
I’ve logged this upgrade behaviour as a bug in MSDN product feedback center (FDBK23852) and we have been communicating intensively with the ASP.NET team through our TAP channels. After delevering a simple reproduction site, the ASP.NET team has proposed a workable solution to this problem. They are now considering this functionality to be added to the upgrade wizard, so that this will save a lot of people doing manual conversions. We have now delivered somewhat larger sites for them to test. I really hope things will succeed and the functionality gets added.
Go ASP.NET team!
I will post follow-ups on this topic as new information becomes known.
3 comments
Follow up:
https://blogs.infosupport.com/raimondb/archive/2005/08/25/1006.aspx
Raimond
I’ve got the same problem as you logged in the MSDN bug. What is the work around for this problem?
Jason Robbins
The first thing you can try is to use the upgrade wizard mentioned in the follow up posting (see above comments). If you are starting with a fresh site however, this is what’s the trick:
Basically the trick is to use the Dependency Inversion Principle from Object Oriented Design, by not making classes depend upon each other, but let both depend upon a third abstraction (an interface for example).
When you need to reference a specific class (page, user control etc) from the ‘Web’ section, create an Interface for the properties and methods you need to share in the ‘App_Code’ section. Then let the page or whatever derive from that Interface, thereby implementing it. When you also want to put some functionality in the Code part, you could do a base class instead of an interface.
Example:
Page.cs
public class PageX : Page, ISharedStuff
{
public int Shared;
}
Code/Interfaces.cs
public interface ISharedStuff
{
public int Shared;
}
Code/Usage.cs
public class SomeCodeClass
{
// oldcode (non working because of circular dependency)
// public DoSomething(PageX instance)
public DoSomething(ISharedStuff instance)
{
DoCoolStuffWithInt(instance.Shared);
}
}
I hope this makes it a bit clear… otherwise, let me know
Raimond