"The base class includes the field 'WebUserControl1', but its type (common_WebUserControl) is not compatible with the type of control (ASP.common_webusercontrol_ascx)" RRS feed

  • Question

  • User-362399677 posted
    Hello. I tried to convert a project from ASP.NET 1.1 to 2.0 and found one big problem which stops the whole process. An .aspx page from the subfolder "admin" includes a user control from the subfolder "common". Both subfolders ("admin" and "common" are in the root). root - admin -- aspx page - common -- user control The page works well when started from Visual Studio, but when the project is precompiled for deployment, the next error occurs: "The base class includes the field 'WebUserControl1', but its type (common_WebUserControl) is not compatible with the type of control (ASP.common_webusercontrol_ascx)" I tried to use "Reference" in the .aspx page, but that doesn't work. Does anybody know any workaround for this?
    Tuesday, February 7, 2006 2:41 PM

All replies

  • User-1634877164 posted

    Hi Net,

    Could you post some sample code of how the user control is being referenced?

    Also -- how are you using the user-control?  Are you programmatically referencing it, or simply declarating and using it on a page?

    Lastly -- does it work when you compile and run in Visual Studio?  Is it only when you do a publish that it fails?



    Wednesday, February 8, 2006 1:42 AM
  • User-362399677 posted
    Hello Scott, Thank you for the reply. I don't use it in the code, just declare it in the way (declaration, usage): ------------------------------------------ Register Src="../common/WebUserControl.ascx" TagName="WebUserControl" TagPrefix="uc1" ... uc1:WebUserControl ID="WebUserControl1" runat="server" ------------------------------------------- (I removed some symbols to make the code appear). I also tried to include "Reference" directive at the page top, but that didn't work. Everything works when I compile the application, even when I launch it from Visual Studio (Shift+F5). This is the point where a hidden reef begins. When I precompiled the project (updatable), the page gives the error. I made several experiments and if I put the control into the same folder, where the page is, everything works ok. Also, I noticed that pages which are in the root can include any controls from "common" subfolder in the same way I described and it works. I.e. I understand that pages may include controls which are in "subfolders", and the problems occur when they include controls from parallel folders. I think this is due to the new compilation model, but maybe there is some workaround. I was searching the forum, but didn't find anything helpful, expect suggestions to use "Reference", which didn't help. Thanks. Ray.
    Wednesday, February 8, 2006 1:44 PM
  • User-1634877164 posted

    Hi Ray,

    You should be able to do this scenario just fine.  If you are just using the control on a page, then you should be able to just use a <%@ Register %> directive (no refrence directive required).

    Can you send me via email (scottgu@microsoft.com) a simple project that shows this problem?  I can then help debug it more and figure out what is going on.



    Wednesday, February 8, 2006 1:57 PM
  • User-362399677 posted
    Hello Scott, I just sent the project to the e-mail you provided. The strange thing is that I tried to make a new project to show the problem and this one works fine. That's why I attached the converted full project. Regards, Ray.
    Wednesday, February 8, 2006 3:06 PM
  • User-2102444038 posted

    Hi guys,

    Did you manage to get anywhere with this? I have exactly the same problem.

    To make things even more confusing I have 5 user controls in a directory, 4 work fine but the 5th (and any subsequent ones I make) cause the error describe above.

    I've also noticed that when you publish the website a strange DLL is created. There are all of the normal DLLs  (App_Web_xxxxxx.dll) but there is an extra one called App_Web_OffendingUserControlName.ascx.xxxxx.dll. This is only DLL that is named this way; and I get one of them for every user control that doesn't work.

    I can also confirm that moving the user control to the same directory as the page that it is used on resolves the issue.


    Thursday, March 23, 2006 6:53 PM
  • User681661554 posted
    Hi everyone,
        I've the some annoyng problem....
    Every time I have an upgrade to publish is a nightmare...

    my "strange" WebUC is in the "admin" subfolder and in the bin folder I have the extra dll "App_Web_adminmenu.ascx.xxxxxx.dll" and it is the only dll that is named in this way.

    I have found a solution that sometimes works...

    After having built the solution, in the pre-compiled site the page that gives me the problem has:

    <%@ Register Src="../admin/adminMenu.ascx" TagName="adminMenu" TagPrefix="uc2" %>

    and the line that thrown the error:

    <uc2:adminMenu ID="AdminMenu1" runat="server" />

    The solution that sometimes work is to give to the UserControl ID the same name of the "TagName" or removing the ID; this pieces of code work:

    <uc2:adminMenu ID="adminMenu" runat="server" />


    <uc2:adminMenu runat="server" />

    I hope this workaround should work for you too..


    PS: SOrry for my bad english...
    Thursday, March 30, 2006 11:00 AM
  • User-1809013715 posted

    Hi everyone,

    I have precisely the same problem provided that I request the compiled application to be updatable (-u switch on aspnet_compiler). Without the switch, the problem disappears.

    Best regards


    Monday, May 8, 2006 5:04 AM
  • User1550782130 posted

    I was getting this problem as well, and think I might have figured out what is going on.  Of course if Scott Gu puts another post up here ... I would go with whatever he suggests.

    The problem that I was having is that I was trying to precompile my site, and then move it to the live server that the site is actually hosted on.  I was getting this error because the machine that I was coding on was running the 64-bit version of the .NET Framework 2.0 (which refers to the extensions at C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727).  It turns out the computer that the site is hosted on is running the 32-bit version of the ASP.NET 2.0 (refers to the extensions at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727).

    So, what I am guessing is that when Visual Studio 2005 precompiles the code it does it with respect to a target version of the framework ... namely whatever version your computer is running.  Then when I moved that code that was designed for the 64-bit version of the .NET Framework 2.0 over to the 32-bit version ... some things that didn't match up (there has to be some differences or you would refer to the same folder for extensions).

    The solution I came up with ... don't precompile the site.  Move the files out there, and the first time the site is hit it will dynamically compile for whatever version of the .NET Framework the server is running.

    Saturday, May 27, 2006 4:44 PM
  • User618559666 posted


    DId you find any resolve to this issue? I am stuck in an identical problem.

    Please let me know


    Friday, June 2, 2006 7:32 AM
  • User19039213 posted

    Hi Guys

    I think i found the solution........

    Just change the CodeFile attribute in Usercontrol html in to CodeBehind ....it will work...

    In asp.net 2003 usercountrol html u get the folowing declaration..

    <%@ Control Language="c#" AutoEventWireup="true" Inherits="xxxxxxxxxxx" CodeFile="xxxxxxxxxxxxxxxxs" %>

    In asp.net 2005

    <%@ Control Language="c#" AutoEventWireup="true" Inherits="xxxxxxxxxx" CodeBehind="xxxxxxxxxxxxxx" %>



    Monday, June 5, 2006 6:26 AM
  • User2112754610 posted

    I can report that changing to CodeBehind did indeed solve the issue. (also reporting that I had the issue)  Doesn't make much sense tho since i have another page that works just fine with the CodeFile attribute.

    The controls are nearly identical (created by a generator).


    Thursday, June 8, 2006 4:27 PM
  • User2112754610 posted

    So this happens every time i regenerate my code, (using .NetTiers and codesmith).

    (I'm leaving it codefile instead of codebehind as I believe codefile is supposed to be the preferred syntax).

    to let you know my configuration:

    I'm using the webadmin controls generated by .NetTiers in a Web Application Project.  The error occurs when I run it on my local machine.

    The page that it occurs on is using a very simple master page and really the only thing on the page is the content control with the NetTiers UC in it.

    As I mentioned before, it doesn't happen on all the user controls generated by NetTiers, but I can't find a difference that would do this between the control that works and the one that needs to be altered to work.


    Thursday, June 8, 2006 7:00 PM
  • User19039213 posted


    try to create a new usercontrol in vs.net 2005. It will create as CodeBehind not as CodeFile. I guess CodeBehind is the suitable property in the vs.net 2005.

    CodeFile willl work with converted .net projects(vs.net 2003 to vs.net 2005). But when you try to add new web form to converted project and try to use an user control of vs.net 2003 version, this error occurs.



    Friday, June 9, 2006 1:05 AM
  • User-102166584 posted

    Hi Ray,

    You should be able to do this scenario just fine.  If you are just using the control on a page, then you should be able to just use a <%@ Register %> directive (no refrence directive required).

    Can you send me via email (scottgu@microsoft.com) a simple project that shows this problem?  I can then help debug it more and figure out what is going on.



    I take it you were unable to repro this using the project that Ray emailed to you (that you requested)? I'm having a similiar issue and would like to hear from you on this :)
    Thursday, July 20, 2006 9:28 PM
  • User-1158376536 posted
    I have the same issue.
    Saturday, July 22, 2006 8:37 AM
  • User-334003078 posted

    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
    Saturday, November 25, 2006 1:28 AM
  • User1747367547 posted

    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. 

    Thursday, December 7, 2006 5:24 PM
  • User379035351 posted

    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.

    Monday, January 1, 2007 6:16 AM
  • User-974026042 posted


    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.










    Wednesday, January 24, 2007 11:13 AM
  • User1927794951 posted

     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?

    Wednesday, February 14, 2007 9:38 PM
  • User618549755 posted
    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.
    Tuesday, February 20, 2007 11:13 AM
  • User108927316 posted
    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.
    Friday, March 9, 2007 1:15 AM
  • User-1569459762 posted
    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?
    Friday, March 16, 2007 7:28 PM
  • User-393330546 posted

    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.

    Wednesday, March 28, 2007 7:22 PM
  • User253469968 posted

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


    Friday, August 10, 2007 8:03 PM
  • User253469968 posted

    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)







    Friday, August 10, 2007 8:34 PM
  • User387490094 posted

    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.


    Tuesday, September 4, 2007 9:24 PM
  • User455536246 posted

    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 [666]

    Monday, November 19, 2007 10:52 PM
  • User-1316326622 posted

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

    Tuesday, July 1, 2008 1:22 PM
  • User-1124979204 posted

    Hi Net,

     Even I experienced the same problem...

    but I have not made any changes to the structure of the website, the usercontrol in question was working perfectly from a long time. It was just on saturday that I got this problem. I tried the solution that you have given here ie. transferring the usercontrol to the same folder as the page. But it will require changing the register tag in all the pages that include the said control. Moreover, did u find the reason why this problem occurred in the first place?

    Awaiting your reply.

    Monday, July 7, 2008 1:45 AM
  • User-648863444 posted

    This solution worked for me right away.
    Removed the ID tag. Is there a reason why the ID tag would cause this error ?

    ****** Worked for me *****************


    Wednesday, February 18, 2009 5:39 PM
  • User108830567 posted


      This run-time error also shows when the mark-up has some invalid format. For example, if the control has this control directive:

    <% Control Language="C#"

    when it should be

    <%@ Control Language="C#"   (NOTE THE @)

    Something small that can get overlooked.

    I hope it helps

    Thursday, May 14, 2009 6:08 PM
  • User-1478099342 posted

    It does solve my problem. I wasted 4 hr try to solve problem by deleting temporaroy files. But this does the trick.

    Friday, June 5, 2009 3:57 PM
  • User-1118405772 posted

    See http://support.microsoft.com/kb/919284.

    It also could happen because Inherits="xxx" attribute has value of unexisting class.

    Thursday, July 2, 2009 3:38 AM
  • User-1541713993 posted


    This problem normally occurs if you keep user controls in diffrent directories or name spaces, moving them to same namespace and physical directry solved this problem for me.

    Hope this helps.



    Friday, September 11, 2009 3:10 PM
  • User-929422073 posted

     We had a similar issue. Our user controls lived in a directory called "Controls"

    In an effort to group related controls some of the user controls were put in subdirectories under the controls directory. We noticed the problem surfaced when a user control in a subdirectory was referring to another  usercontrol in the parent directory (eg A SearchList control in the \Controls\SearchItems directory used a ModalDialogue control in the \Controls Directory.

    A clone of the ModalDialogue Control was created in the \Controls\SearchItems subdirectory. The new control was given a different name (ModalDialogTest) to be sure to isolate which control was being used. This worked fine. We then hit on the idea of parking the modal dialogue control in its own subdirectory. (out from the parent "\Controls" directory)

    A Subdirectory was created "\Controls\Modal". Our ModalDialogue control was created in this subdirectory and it cured the problem.  I hope this helps someone out.

    Friday, October 9, 2009 12:17 AM
  • User1296560227 posted



    I had the same problem, after I made change according to what Maduka suggested, eveything works fine now.


    Wednesday, October 14, 2009 5:13 PM
  • User-1274353093 posted

    hey i have encountered a similar problem but in .net 3.5. i have tried all the solutions mentioned here for .net 2.0 i.e. vs2005.. my app was developed in vs2003 v1.1 and then converted to vs2008 v3.5. earlier this problem was not there and the website was running w/o any glitch but this problem occurred suddenly a few weeks back.. i've been trying to solve it but in vain. can anyone please suggest what i should do? 

    Monday, October 19, 2009 10:15 AM
  • User1296560227 posted

    Hi, have you tried the possible solution suggested by Maduka?

    Here it is:


    try to create a new usercontrol in vs.net 2005. It will create as CodeBehind not as CodeFile. I guess CodeBehind is the suitable property in the vs.net 2005.

    CodeFile willl work with converted .net projects(vs.net 2003 to vs.net 2005). But when you try to add new web form to converted project and try to use an user control of vs.net 2003 version, this error occurs.



    Monday, October 19, 2009 7:07 PM
  • User-1274353093 posted

    thanks for the suggestion but  this solution is not applicable in vs 2008.. the usercontrol comes with the codefile tag and not the codebehind tag by default.. if u mention the codebehind it throws a compilation error.. is there any other solution?

    Tuesday, October 20, 2009 1:44 AM
  • User1611391320 posted

    In the reference the path of the control given must be ~/Common/User.ascx.


    Tuesday, October 20, 2009 2:00 AM
  • User-153453152 posted

    When You enable, "Use fixed Name namespaces and single assemblies for all files", while publishing a web site. then the building process will consolidate your directory level files into single DLL and merge your classes into the same DLL. Which will create problems for the websites which are using subdirectories in their project.

    That meas, who ever using root folder as one and only directory then there will not be any problem, but once we started using subdirectories then we need to have different DLLs for each files. Otherwise at the runtime it will throw this error.

    Friday, December 11, 2009 7:57 AM