Hi All!
I'v created some UserControls in *.ascx files in my VS 2005 web site project. Also I'v created some classes in /Code/*.cs files in site folder that need to use early creaded usercontrols. But when I start compilation the next error have procesed:

"error CS0234: The type or namespace name 'Blablabla' does not exist in the namespace 'MySite.MyUserContrls' (are you missing an assembly reference?)"

After this I'v started aspnet_compile utility for creating full precompilation of *.as*x files and processed same error, because this utility compile site in two steps and compile class library files first.

Can I use one-step precompilation of my site? Or I need to write extreaml MSBuild pre-compilation script, or need to re-design my site architecture?

Thanks for all

I need more information. Asp.Net will build the code folder and pass the resultiing assembly as a reference to each page\user control it needs to build. Where is the namespace it is complaining about defined?

The compilation for asp.net 2.0 compiles the code directory before the pages/controls. This means that you will have a problem if you are trying to refer to the controls from within the contents of the code directory.

How much of the control do you need to reference from code. One [hacky] answer would be to create a base class in the code directory for each control you need to reference, and put the properties/methods you need in that base class. You can then use that base class for the control, and override the properties/methods as necessary.

Sam

I have the same problem.  I have classes that I used to just toss in a folder (_Classes).  These were "facade" level classes that needed to live in the web application project since they needed access to session, etc.  I also had some helper methods that would do things like take data in and out of user controls. 

The problem now is that my pages don't seem able to reference these classes unless I put them in the app_code folder.  Once I put them there, however, they can no longer reference the user controls.  I seem to be in a catch22. 

I'm sure I can learn to deal and even appreciate the new design, but all the articles I keep reading start off with "ASP.NET 2.0 is 100% backwards compatible."  However, with issues such as these, I find myself with a huge amount of refactoring before I can proceed forward. 

What am I missing?

VS03 compiled all content pages (webform, controls) into one assembly; VS05 compiles each content page (along with its code-behind if there) into its own assembly. As a result, code in the App_Code folder cannot access the page anymore, so you get a broken reference.

Sam mentioned a workaround for this situation. You need to create an abstract base class for the control in the App_Code folder (lets call this the stub file). This will allow your code to compile (since it can find the reference in App_Code) and allows the runtime to do a late binding to your real control (outside of App_Code).

For example, lets assume you have the following (where C1 and C2 are controls, and S1 is a standalone code file):

V1 App:
AppRoot
  C1.ascx      // inherits=”C1”
  C1.ascx.cs   // class C1 : System.Web.UI.Page { public void foo() {} }
  C2.ascx
  C2.ascx.cs   // C1 myC1 = (C1)LoadControl(“C1.ascx”)
  S1.cs      // instantiates an C1 object which calls foo()

V2 App:
AppRoot
  C1.ascx      // inherits=”mod_C1”
  C1.ascx.cs   // class mod_C1 : C1 { override public void foo() {} }
  C2.ascx
  C2.ascx.cs   // works since it will call the stub file
  App_Code
    stub_C1.ascx.cs   
    // abstract class C1 : System.Web.UI.Page { 
    //   abstract public void foo(); }      
    S1.cs      // works since it will call the stub file

Things to note:

1. File names and class names do not have to match. Hence the stub file contains the original class name "C1" and the referenced control has a modified class name "mod_C1" (and has C1 as a base class). You actually can keep the same file name in App_Code, but I prefer to show it is a stub by naming the file explicitly that way.
2. This naming means you don't have to change the referencing/calling page or control, since it will still refer to the original class name (which is now in the stub).
3. Not all controls need a stub file, just those controls which are referenced by another control. Hence C2 did not need a stub file, since no other page is referencing that control.
4. This approach should work in most cases, but there are probably edge cases where it may fail. For example, an abstract class cannot be instanciated so if your code does this it is going to fail. You might try using a normal base class rather than an abstract base class at that point.

I hope that helps; I wish it could be easier.

Ignore this.

Doh. I wanted to set the option to "Email me replies to this post" so I wrote a one-line to ignore my little post to set the option (not to ignore the big post I just did). Sorry about the confusion...

While this work around may work in some scenerios it's a really bad idea for pages that are complex and contain lots of controls. What you suggest gives access to the underlying base class and methods, but it really makes it even harder than it already was to access controls on page.

This basically blows even the limited 'visual inheritance' mechanism that VS 2003 had away. The only way you can access controls now is with FindControl, which is inefficient and prone to errors as it lacks strong type support.

It seems to me there should be some way to consolidate this. Master Pages appear to be globally visible - they have to be - so why not pages in the same way (MasterPages and controls appear to compile into separate assemblies).

IMHO, this is a big problem for a number of applications especially ported applications. Just about all of my apps did some of this for their templating/theming support or merely providing some limited visual inheritance. All that is broken and needs manual fix up.

 

You raise a good point. Using a stub class is not a recommended practice for new applications -- my post is really meant to help ASP.NET 1.x developers port their web apps to 2.0 more quickly. A new web app should use the appropriate attribute tag to explicitly reference another user control.

Master pages and user controls are similar in level of access, i.e. master pages are not globally visable so you have to use an attribute to find the master page too.

We realize that cross-referenced user controls are a migration issue and are working on ways of improving our migration in this area. In the meantime, hopefully the workaround posted here will help early adopters.

Hmmm... maybe I'm missing something, but I CAN see master pages in Intellisense and I CAN reference them in code without problem.

This has to be this way since you are passing Page.Master back and we need to be able to cast the Master page to a specific page. The following works for me in a content page:

SiteMaster ParentPage = this.Master as SiteMaster ;

ParentPage.PageTitle = "West Wind Articles Archive";

Note that I can cast to SiteMaster here so the Master Page IS visible to other pages. Since Masters are really just custom controls using the same partial class compilation model this same sort thing ought to be possible with Page classes.

+++ Rick ---

 

So how do you suggest we do this in 2.0 (I have the problem but not in a migrated project).  I have a page where I want to load controls dynamically, but making sure I have a <% reference %> in the page as well as in the codebehind seems asinine to me.  Its not about backwards compatibility, but assembly generation.  Is one assembly per page the only way to do it?  I expect to deploy the site as a single file, why can't I debug it this way?

I have no idea how this should work either and unfortunately contrarty to Michaels post that seems to imply that MS was still working on this, the behavior has not changed all the way up to the RC now.

There are a number of people who've major issues with this - especially people with frameworks (like DotNetNuke) which rely almost exclusively on dynamically loaded controls that they can now no longer access.

The only workaround I see is to implement a base class and casting to that as I mentioned earlier in the thread. This is really not a heck of a lot better than the explicit <%@Register tag as it means that you can't do this generically. And in some cases it's not possible to inject into the class hierarchy if the control is previously subclassed.

It sucks - this is IMHO a major oversight and design flaw in ASP.NET 2.0... they've taken away a very powerful feature for the sake of simplicity in the compiler model, which is not worth the the trade off. Worst of all there could have been ways to fix this by having the compiler provide a more comprehensive mechanism for associating assemblies or still providing single assembly compilation...

Oh well, now we're stuck with it...

The change to use multiple assemblies is just one of many changes in the web project system to improve performance and make it easier to develop web apps. If you have not done so already, you should check out ScottGu's blog post on the subject at http://weblogs.asp.net/scottgu/archive/2005/08/21/423201.aspx 

Thanks,

I've been told the "performance improvement", but since no compilation is happening at runtime in most large sites, I don't see multiple assemblies as being a performance improvement.  Perhaps at development time.  (I have read on Scotts blog about a new tool to allow compilation to a single assembly for deployment.)

But to understand what you said, how does multiple assemblies help "make it easier to develop web apps"?  Easier for the ASP set who want do drop their code on a server and have it auto-compile, sure.  But again, for most enterprise-sized applications this is a security risk and encourages the black days of developers having access to the web servers to fix issues.  This certainly feels like a step backwards, not forwards.

Michael,

With all due respect to Scott, but what Scott describes in that post is a hack! It's a workaround for a design problem that many people have pointed out very early on in the product cycle and have been ignored by the ASP.NET team.What's interesting to me is that the people that are complaining about this most are many of the gurus who supposedly know how to take best advantage of the tool - that's always a bad sign when your most loyal supporters end up being the loudest for criticizing a feature.

This isn't the last you're going to hear about this problem either - once ASP.NET ships and more developers will actually build real applications with it you will see many more developers run into this issue.

Part of the problem too is that even for new development this will be a huge issue, because once you get to the point where you need to dynamically drop controls there aren't a whole lot of workable options to do it and you're stuck.

+++ Rick ---