Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Dec 11, 2009 11:57 AM by nagappmking
Feb 15, 2007 01:38 AM|LINK
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:
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
then including page(or user control) and referenced user control
must be at the same directory.
Is it correct description of the rule?
Feb 20, 2007 03:13 PM|LINK
Mar 09, 2007 05:15 AM|LINK
Mar 16, 2007 11:28 PM|LINK
Mar 28, 2007 11:22 PM|LINK
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.
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.
Web Application Projects
Aug 11, 2007 12:03 AM|LINK
How come when i try changing CodeFile to CodeBehind i get a compiler error saying 'could not load' codebhind file?
Aug 11, 2007 12:34 AM|LINK
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)
Sep 05, 2007 01:24 AM|LINK
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.
Nov 20, 2007 02:52 AM|LINK
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 
Jul 01, 2008 05:22 PM|LINK
"Use fixed naming and single page assemblies" did the trick.