We were having this problem all of the time while developing a site with many user controls located within sub-directories.  I had to compile the site 3-6 times before it would successfully compile.  We finally figured out that a reference added to eash aspx page that used the control resolved the problem.  Now we have no problems getting the site to compile.  The code has not been pushed to our production servers yet, so I don't know if this fix will stand the test of time.

Example:

<%

@ Reference Control="~/UserControls/Filter/Month.ascx" %>

 

I have the same Problem as all you guys... Alwasy when i update one of the Layoutfiles of the usercontrols, i get the Error..

Ich have about 20 usercontrols, all compiled with code behind. But whe I update navigation.ascx, then i get an Error in artikel.ascx and userbox.ascx.

When you clear the Tempory ASP.net Files it will work. But that's a bad solution! Because i don't have the permission to delete the temporary folder from my Provider who hosts my Webshop. Or do you know a script how i can do that?

 

Thanks blampright!  I've been developing a site and every time I make a modification to my user control I get that error.  I tried your suggestion and so far it seems to be working.  That'll save a lot of time (and frustration) not having to rebuild the site every time I make a tiny change.

Has this problem been solved? I have SP1 installed and am still receiving this error seemingly randomly. Does anyone know what the status of this issue is?

Hi guys,

We had a first occurrence of this yesterday on our production license server.
(Believe me, that upset a lot of people!) Debug is set to false, so personally I
don't believe that's related. Nothing was changed on the server at the time
of the error (it was 3:00am in the morning), so I concur that it seems to happen
at random.

What's the news from Microsoft?
Is it confirmed that the hotfix actually fixes the problem?
EIGHT months from the first report and still no solution is a pretty poor show
I would say.

Cheers,
Geoff

Wow if someone non-Microsoft can actually come up with a true solution for this they'll definitely be my hero :)

As I mentioned in my previous post on this thread, I have been in contact with MS Support and they have been proactive about trying to help.  However, as would be typical, I cannot get the exception to occur now that I opened a support case with them.  It's frustrating because you can't force the problem to happen - it just has a mind of it's own.  So while it's not ideal that you have to call support and start a case (which means it's on your dime until they determine it is a MS bug not your code), they are willing to help and it's a matter of time before we can get the debug results they need from me.

To summarize, MS is helping me, but the intermittency of the error is a major roadblock.

 

So I came to this forum looking for a solution to my IBM.Data.DB2 dll missing even though its there and I found everyone griping about a problem I seem to have already found the solution to. If you get that nasty ass cant find App_Web1231241 whatever error on your production servers add the following key to the web.config file :: 

<compilation debug="true" batch="false"/>

I think what is happening is that the ASP.NET worker process tries to build everything as one DLL and it messes up. This happens when you do non-standard builds. By that I mean modifying backend HTML / server side code w.o doing a full deployment. So you find some little issue in an .aspx file modify that and you think you're good to go.  Try that and see if it works. We reported this issue to Microsuck about 3 months ago through our corp support account and pointed them in the right direction. Guess they need to set the crayons down and do some bug fixing.

Let me know if that worked or if I just went on my rant for no reason slyfox3k@yahoo.com

<compilation debug="true" batch="false"/>

Thanks for the suggestion, but it didn't work for me.

- Chuck
 

I just wanted to post that while I never had this in production, we used to have this constantly on our development server.  It seemed to go away when we upgrade the RAM from 2GB to 4GB.  Now it is back, after we recently added a continually running virtual machine to this server.  I have also noticed VS2005 behaves much better (not just faster - less buggy too) on my machine since I went from 512MB to 1GB.

Has anyone else had similar experiences?  Is anyone using a ton of RAM (> 4GB for a small site on a dedicated machine) that is still having this problem?

I had this problem a long while ago and I've seen the bug both in .NET 1.1 and .NET 2.0.  I figured out that it was most definitely related to user controls having other controls (user or compiled dll's, both break it) inside of them.  Here's a snippet of what we found to be the work-around (for .NET 2.0, use the appropriate equivalent directory, for various other security configurations, improvise on top of this):

The work-around is that you give the user that the .NET application is impersonating (impersonate=true, with a domain account set as the anonymous user to run as, at least in this case) read/write/modify permissions to the:
c:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\root\
directory (and make damned sure that account is not compromised otherwise you risk code injection into ASP.NET applications) and the problem magically goes away.

Good luck!

This way happening to me on my dev environment and the fix was imply to run a "Clean" in Visual Studio 2005 and then build the solution again.

I had this problem four times since December. It happened today again and nothing was updated or done to the server.

This is what fixed it before: 

First: reseting IIS

Second: Repaired the framework

Third: Deleted the files from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files directory

Fouth:  None of the above seemed to fix it.....re-registered the aspnet account with the framework, installed the framework as well, and still nothing...I have never had this problem before with any .net code. Don't know if it has anything to do with what else runs on the server, since I recently changed jobs and working with different servers and setup.  Any ideas????  

Hello,

Just had the same problem for the first time.

The server has 2 GB of RAM

It happent just after I updated a page (with usercontrols, but not usercontrols using other userControls) wigthout building the whole site afterwards.

It was fixed by just stopping and the starting the site (not IIS, just the site)

We had this problem a couple of times, too.  What's interesting is our site uses a different set of user controls based on the item a customer is purchasing.  When the app went down, only one product was causing the error.  After reading this thread, I don't think it's coincidental that the product having the issue was using a nested user control, while the product not having the problem had a flat single user control structure.

In our case, copying the user control from Test to Prod fixed the problem the first couple of times.  Since then, we've replaced the nested user control with a flat structure.  We haven't seen the issue for about a week.  Not sure if it's been fixed, or just hasn't errored yet...