Does anyone have an answer to the above question? I am running into the same thing, using Beta 2 and its a major roadblock for us.

Thanks in advance.

Non-page related files will be moved to the App_Code dir, which includes the .cs or .vb files. The new dynamically compilation model will compile code into different assemblies, so because of this you need to add the Reference directive to the page that will point to the virtual path where the User control is located before you can for example cast your user control to its right type.

Thanks Fredrik,

Sorry about the clarity of my post, the problem I am having is that the classes in the App_Code folder cannot find a reference to classes used for Pages and UserControls.

So class "A" is in the App_Code folder and is trying to instantiate a WebUserControl "AControl"

AControl a = new AControl();

The compiler returns The type or namespace name 'AControl' cannot be found .....etc

Is there someway this class can reference Page and UserControls?

Thanks for you help.

Williams,

The issue you are seeing is due to the fact that app_code is compiled separately [and before pages/uc are compiled in the app] and has no references to pages/controls existing outside this directory. One possible workaround can be that you declare a base UserControl class in app_code - use this to do the instantiation and make your usercontrols derive from this UC class.

Thanks, Kashif

Yes. this is a work around.

Additionally, if you keep same name for new class in App_Code, and give a new name to Code behind class say, class MyUserControl_Imp : MyUserControl you just need to change the name only at the current page (change Inherits="MyUserControl_Imp") and the code behind file. You donot have to change other places where it is referenced.

You donot take this approach for all CB classes, only the classes referred from App_Code or any other Code Beside  file. How about getting it done automatically?

Baiju

Some automated way of doing this may be a benefit - although I think the ideal (i.e. zero work for me and zero code changes) solution would be if Whidbey had a "compile everything into one dll like Visual Studio 2003" option.   I do however appreciate that this option may not be favourable (or indeed possible) considering the new aspx/ascx inheritance & compilation models.

Are you the same Baiju who wrote the blog (http://blogs.msdn.com/baiju/archive/2004/11/15/257866.aspx)?  If so I guess you are pretty familiar with the conversion tool and Whidbey.  In your opinion (and I am not going to hold you to this ) is this "1.1 compilation" option feasible and is there a realistic chance such a feature may be included in the final release of Whidbey?  How many developers would have to whinge (and how loudly) to get  this feature in?
 
If this feature is not possible then obviously some automated way of doing would help.  Is it feasible that the conversion tool could be modified to deal with this problem?  I don't particularly like Kashif's suggested work around (because of the need to create otherwise redundant base classes) but in lieu of a more elegant solution, could the conversion tool do this for us?

Obviously there are many, many businesses that have (like my company) developed large and fairly complex web apps under 1.1 which will suffer from this problem- and I think none of us relish the idea of having to chop and change our code around just to get them to compile with Whidbey.  On the other hand, we would like to start developing with .Net 2.0 because we can see the tangible benefits the language & framework improvements, VS2005 (& Team studio) will bring.  We really (really) want a nice and easy (i.e. low developer effort) upgrade path.

On a brighter note let me add that all our windows code (C# and VB.Net) went through the conversion tool and compiled and run with no extra modifications . 

Chris,

Let me answer for Baiju. When we designed VSO5, we made a decision not to support the ASP.NET 1.1 model in the IDE. You can run your 1.1 web app in the ASP.NET 2.0 compatibility mode during runtime, but it would have added unreasonable complexity to VS05 to have it support both the 1.1 and 2.0 compilation features.

So we provided a migration feature to convert web apps from 1.1 to 2.0. Our goal is minimize the amount of manual work needed to migrate your web app. But given the extensive 2.0 changes for web projects, it is expected some manual migration work will be needed. We will do everything reasonable to minimize this work.

We are even looking to automate the solution suggested in this forum thread. In addition, we are creating a white paper which will document this and other migration issues and their solutions. We will be sure to post a link to this on these forums when it is finished.

Thanks,

Check out my posting here -- it gives the general idea.

http://forums.asp.net/927765/ShowPost.aspx

Pondered and played with this a bit more over and weekend and I've come to decide that I really don't care for this new build model (all the seperate DLL's). What it seems like to me is that its introduced a new namespace style heirarchy to the build process that isn't openly intuitive and sets up roadblocks to assembly cross referrences that isn't readily apparent to the basic developer.

I would really prefer to see a fix for this rather then hack-job style workarounds. Yes the new model helps force people into thinking a bit more carefully about how applications are designed/built, but it also throws some significant roadblocks into the development process and increases the learning curve for the product.

At a minimum, it would be nice to have an option for the old style assembly creation (one dll for the website). Thus allowing older applications to be more easily migrated forward while helping encourage the new build methodology for newer applications. At the very least, make sure this new build order is clearly details and readily accessible for all developers moving to VS 2005.

Yes, it is making things more complicated.

Please remeber that a code-behind accessing user control can be solved by <@Reference > Tag in the page.
This abstarct base class is needed only when some stand alone code (in App_Code folder)  accessing code-behind classes (outside App_Code).