I've experienced this bug, too. It's extremely annoying and I really hope Microsoft are prioritising this because it needs addressing ASAP.

I too am struggling with this issue. I rarerly eveer saw this problem, but a few weeks ago I started using the Atlas framework in my site and now the problem occurs several times a week. In fact, it happened about 5 times today. I have my site "armed" to email me whenever the problem happens so that I can manually fix it. This has been painful and I am running out of ideas. I am considering removing all of the cool Atlas enhancements in hopes that I reduce the frequency of this problem.

Ryan Covell

 

Has anyone else noticed that disabling the debug in web.config seems to avoid this error?  We have an application we are pushing out, and have experienced this problem.  I disabled debug in the web.config in our test environment, I'll report if we do not see the problem persist (although it seems like a hard bug to recreate).

I installed the hotfix, and it works fine at beginning. I haven't seen the same error for the past 3 weeks, but UNFORTUNATELY, the problem showed up again today. I then decided to come here to see if there is any new development on this issue, and I foudn ICGopher's reply: 

ICGopher:

Has anyone else noticed that disabling the debug in web.config seems to avoid this error?  We have an application we are pushing out, and have experienced this problem.  I disabled debug in the web.config in our test environment, I'll report if we do not see the problem persist (although it seems like a hard bug to recreate).

 I tried the same thing. I simply turned off debug WITHOUT manually modifying the page, and the error message disappeared.

I will keep an eye on this, and I hope this way works. If so, at least we can have a problem-free production server.

Check your project name in common properties.general tab -> Assembly Name and in app.config configuration\configSections

try clearing the Temporary ASP.NET Files FOLDER in the Windows folder and then try to compile it. it will work.

I have noticed this problem seems to occur the most frequently when a page uses nested user controls, if that's of any help to anyone.

It's been a week since we disabled debug in our web.config file in our test environment, and we have not seen the problem recur.  We are pushing the site live at the end of the week, hopefully this has solved the problem.

Hi guys,

I've the same problem, too.

My debug option in web.config file is always false... but I've the problem anyway.

I'm thinking about installing the hotfix... but I'm scared . I don't want to install something that is not completely tested.

When I've this problem I simply edit/save my main master page file (I use nested master pages)... this will require a recompile... and so web application starts to serve requests again.

When will MS release the official/supported/tested FIX for this problem?

Thanks,

Bye

I concur that is a problem with nested user controls.  Debug is set to false in production.

 Yes, clearing Temporary ASP.NET Files solves the problem but that is not the ideal solution.  The solution would be to figure out the cause and fix it.

 I contacted Microsoft and received a "hotfix patch" regarding KB915782 but that did not work.
 

I cannot verify that the problem is related to nested user controls. However, I notice it most when I make a change to any of my web.config files; especially changes regarding authentication, authorization or impersonation.

The value of the debug setting is irrelevant to the appearance of this error in 2 of my environments. It happens whether debug is true or false. However, all I have to do to "fix" the error is change the value of debug and everything works again. I can then switch the debug setting back to it's original value and move on.

I want to goof around with a test project and find the key to reproduce this problem consistently, but time is no friend now.

Good luck to everyone. We need a true fix soon! 

We are having a similar problem in our Dev Server. I have narrowed down the problem to the following UserControl

Page 1 has UserControl A which uses UsesControl B. The Register for UserControl B is on UserControl A but not on the Page 1.

Does anyone know when SP1 is going to be available in the meantime this post from another thread(different newsgroup might be useful).

 "And in most cases,
the problem is caused by some page which include or reference some other
ascx usercontrols or uesrcontrols has nested usercontrols.... Is this
also your case? For test, when the application running correctly ,you can
go to the .NET 2.0's ASP.NET temporarly dir and find the problem assembly
(App_Web_nr8ih6ru, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null' in your case) and use reflector to check what's the
page and usercontrols in this assembly.

Meanwhile, you can also try avoid this issue by either turning off batching
- in web.config, set <compilation batch="false"/>, or, when the error
occurs, do a clean re-build for the application using precompilation tool:

aspnet_compiler -v <your app name> -c

This will force a clean re-build for your application. It will shorten
response time for first request dramatically. (It is recommended to always
do a clean re-build whenever changes made to a web site.)"

It is included in the following link

http://www.velocityreviews.com/forums/t119679-20-problem.html

 

 

 

We also have been having this problem with several sites across several servers. I've been tracking this thread for months trying different suggestions. This thread has been helpful and here are some conclusions:

• The problem does seem to occur randomly and without predictability.
• It does ONLY happen (in my case) in ASPX forms that do contain embedded custom user controls. It doesn't affect the entire site, only these forms.
• Clearing the temp directory does give temporary relief, but it WILL happen again.
• The patch DOESN'T work!

What does seem to work is Gunjan's suggestion of using the precompilation tool. This seems huge since the error does seem to occur with "In Place Compilation". Pre-Compilation seems to fix the problem but is less developmentally freindly. So what I've done is I use "In Place" compilation for my development site and when it's time for an update I run the aspnet_compiler specifying <targetDir> to compile into a production target directory. There will be no source code in this directory and you can't make changes here. All coding is done in the dev site and if the dev site hoses with this error, I don't get a call from the President on the red phone.

Here's a pretty good link explaining the compilation modes:

http://west-wind.com/weblog/posts/2128.aspx

Also check out the VS 2005 on-line help for ASP.NET Compilation Tool(Aspnet_compiler.exe)

 

 

 

Hi!

Has anyone found the answer for this one?

No matter what I do I am still getting this error! Talk about frustrating!

I have also tried switching off debug in the web.config but no joy.

<compilation debug="false">

Has anyone got any advice please?

thermalnoise:

I concur that is a problem with nested user controls.  Debug is set to false in production.

 Yes, clearing Temporary ASP.NET Files solves the problem but that is not the ideal solution.  The solution would be to figure out the cause and fix it.

 I contacted Microsoft and received a "hotfix patch" regarding KB915782 but that did not work.

I have been in contact with MS Support over the last month or so, but due to the random, uncontrolled occurrence of the error, we have not gotten reliable debug information, yet.  I am hoping the next time the error happens, I can get a good debug file for MS.