I have the same issue.

I had the same problem.  I had to move the control that I created into the folder of the page that I was putting it on in order for it not to give me the following error:

The base class includes the field 'MainToolbarMenu1', but its type (Web.Common.UserControls.MainToolbarMenu) is not compatible with the type of control (ASP.web_common_usercontrols_maintoolbarmenu_ascx).

 Check out this link: http://support.microsoft.com/kb/919284

I was having the same issue and ran across this thread. This was only happening to me when I did a precompiled site.  I noticed in the compiled ASCX file, it said

<%@ control language="C#" autoeventwireup="true" inherits="ApplicationContactTypeCheckBoxList, App_Web_dbsj1fkk" %>

However, in my bin folder, there was a file called App_Web_applicationcontacttypecheckboxlist.ascx.77ebd44d.dll

When I changed the inherits to inherits="ApplicationContactTypeCheckBoxList, App_Web_applicationcontacttypecheckboxlist.ascx.77ebd44d" the problem went away.  Seems to me that Visual Studio is putting the wrong type in the inherits property, or it's compiling that user control into a different assembly for some reason.   All of the other user controls in that folder are inheriting from "App_Web_dbsj1fkk".

Then out of curiosity, I took a look at both DLLs in the object browser.

That user control is compiled into both DLLs.  There's more going on here than I fully understand, but I have a useable workaround for now. 

I kept getting this problem when updating usercontrols and the binary but it seemed to happen once I added .net 2.0 to the server.

As it is an intermittent problem, I have found it impossible to recreate. I do, however, have a solution of sorts.

If you dont have admin access to the IIS server involved you're not going to be able to use this solution.

As soon as you get the "base class usercontrol error", get access to the IIS server where the site is hosted.

1) Open the properties for the offending site.
2) Select the Home Directory tab
3) Under Application Settings, click Remove
4) Create a new Application using the same button

That should sort out all the bad class references.

All,

Here is something...

I use a control called "Address". It is a simple address entry form. Use it in a couple of places.

 On my dev platform...

I debug my code and on page "A" works, the other, page "B" gets the "base class usercontrol error".

When the site is on production...

Page "A" doesn't work, and the page "B" does.

The rest of the code is the same. Is it an IIS config issue?

I am beating my head against the wall.

HPB 

 

 

 

 

 

 

 

 

ZMAN11:

 
 I had to move the control that I created into the folder of the page that I was putting it on...  Check out this link: http://support.microsoft.com/kb/919284

As I understand , the issue is the following:
1.If I am using Web Site model (not WAP)
2. If I want to precompile the web site and

3. do not have "Use fixed naming and single page assemblies" checkbox ticked.

4 if my pages or user controls has references to another controls like the following

<%@ Register TagPrefix="dnn" TagName="Roles" Src="~/Admin/Security/SecurityRoles.ascx" %>

then including page(or user control) and referenced user control must be at the same directory.

Is it correct description of the rule?

From my experience (I just had this happen to me today) it was giving me this same error, and the CodeBehind did fix it... The issue in my case kept complaining about the Global Namespace not containing the control... Which is right, I had my control in my own namespace...  So is perhaps the reasoning that CodeFile= assuming that your class is in App_Code and that it appears in the global namespace, whereas CodeBehind does not make this assumption?  I am only applying the only logic I can think of here... but I'm not claiming to know that this is true or not... Just makes sense that way to me.

When I had this issue, it was because I had forgotten to uncheck the "Allow this precompiled site to be updatable." check box when I published my site.  Previous deployments of the site were deployed with this checkbox unchecked, so when I tried to deploy with the option above, this error occurred.  The only pages that I had issues with was the ones with user controls.  Hope this helps.

Ohhh my gosh. Thank you for publishing this...it ended my 3-4 hour ranting. Okay....what the heck is going on here?? Is there a patch for this now. Is there something I can do to avoid this problem? I have many controls that hit this issue. Seems like all my composite controls. Why is it putting those references there?

Here's a summary and an approach that works consistently for me. I've been whacking through this problem for the last day. Given the variation of explanations on this thread, and my own inability to consistently duplicate the problem, I strongly suspect quirks in control designers and the compilation model for web projects contribute to the problem, or at least complicate finding solutions.

Before explanations, my recommendations:
1. If you spend more than 5 minutes on a quirky problem like this in ASP.NET web projects, manually clean the build. You may need to turn off your web server and dump the files in your temporary ASP.NET folder for the site. E.g. Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\My site

2. To get controls to work nicely and easily in web application projects and web site projects, use them the expected "VS 2005 way". You only need to do this if you are having a problem - you don't need to update all 1000 pages in your monster site. The following apply both to the controls and the pages you put them on.

• Use <%@page CodeBehind="x" %>, not <%@page CodeFile="x" %> (see previous post by Maduka ). 
• Make sure your controls and pages has a designer (webform.aspx.designer.cs) file. This ensures correct declaration, and is respected by run-time compilation in a way that declarations of controls in your own page are not. Web site projects do not appear to need the designer file. 
• Make sure all your pages and controls are declared as "partial" classes, even if you don't have the aspx.designer.cs class present.

3. MS page and control designers sometimes get confused and don't reflect new changes. There are a variety of ways to de-confuse and force them to reset. E.g. go fiddle with something in the design view (e.g. add a control) and make sure that the designer file was updatded.

That said, I haven't been able to consistently get the problem to occur with by going against any of the above recommendations ("CodeFile" in the directive most commonly causes it, as does designer confusion). Using the above recommendations, plus manually cleaning builds, I'm consistently solving it when it rears it's ugly head.

 Expanations - my context:

Context: Large VS 2003 web application project ported to VS 2005 "web project". I've been adding user controls (from VS 2005) and geting a problem similar to the thread topic: "The base class includes the field 'WebUserControl1', but its type (common_WebUserControl) is not compatible with the type of control (ASP.common_webusercontrol_ascx)"

Explanations -getting clean builds in web projects

I finally started making progress when I discovered that in a web application project, "clean" and "rebuild" don't mean what I hoped they meant. Here's what I saw:
1) I created two user controls "A" and "B" in a web project.
2) I add a mis-configured control A to a test page. Build and test. Get error message.
3) I change the test page, removing control A entirely and adding control B
4) Execute VS 2005 "Clean" command, VS 2005 "Rebuild" command
5) I'd see the same error, still referring to control A - which should no longer exist on the page.

Conclusion: I'm having problems because the binary associated with the control or page (each gets its own binary) is not up to date. Obviously, this makes it difficult to validate to correctly identify the problem. I cycle through lots of options, only to discover that the previous fix attempt was never applied.

Note that I have not seen this build problem in "web site" projects, only "web projects" with the csproj files. To get a proper rebuild, STOP the web server (also VS 2005 web dev server), then rebuild. I sometimes need to delete the Temporary ASP.NET files for the site as well. To validate that you are I'm working with the rebuilt page, I make some visually apparent change in the code behind (e.g. change control text) and make sure it shows up.

Other posts have suggested they've solved this problem by changing how the web application is published, or deleting the web application entirely: these are other ways of forcing a cleanup of the temporary ASP.NET files.

How come when i try changing CodeFile to CodeBehind i get a compiler error saying 'could not load' codebhind file?

 

unchecking the 'Allow precompiled site to be updateable' option fixed it for me, but i would like to know why? I have never had to uncheck this option previously!

 My problem stemmed from a user_control which i had embedded within another User_Control.

 I only got the error when viewing the web app after deployment, it worked fine when debugging within VS2005.

I never found changing the CodeFile attribute to CodeBehind to be of any use, furthermore contrary to what i have seen posted, my experience is that VS2005 does not (by default) give you the 'CodeBehind' (it always defaults to CodeFile) property as an option within the Register tag line!! (and brings up a compile error when you put it in, and try to build the solution)

 

 

 

 

 

 

as someone previous mentioned, what seems to fix the problem is to turn off update when you publish. 

1) go to the menu item Build -> Publish Web Site

2) turn off  the option "Allow this precompiled state to be updatable"  (This is on by default)

3) Make sure you deleted your old precompiled website

4) hit okay in the dialog.

Hopefully this gets fixed in 2008.

 

I just had this issue and turning off the "Allow this precompiled state to be updatable" was not an option. If I do then Reporting Services reports on my website do not work.

Rather, the work around that I used was to check "Use fixed naming and single page assemblies". This corrected the issue. One presumes that that this does not have any detrimental impact - it's just a different way of the compiler organising its dlls...?

 Hopefully this gets fixed and new bug replaces it in 2008

 "Use fixed naming and single page assemblies" did the trick.