Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Feb 27, 2010 02:32 PM by efess
Feb 27, 2007 12:38 PM|LINK
I can confirm about the user controls creating the problem having a nested user control. However, the control creating the problem (and there's only one) is not the only one in that situation. Perhaps it is because its the first showing up in the code that
it always seems to have problems with that particular control, though.
I observed the error usually happens after a server reboot, but it also happens at random during the day after uploading a file to another website(folder) on our developpment server. Reuploading the master page, even without changing it, fixes the problem
for the moment, but theres no telling when it'll happen again.
Then I'm thinking, maybe its the way the controls are declared on the page? What if its just one attribute that was forgotten when this was built? (I'm not the one who originally made this website.)
'this is the control that causes the error
<%@ Register src="~/objects/AdminMenu.ascx" TagName="AdminMenu" TagPrefix="object1" %>
'and this is the user control declaration in the AdminMenu.ascx
<%@ Register src="AddBloc.ascx" TagName="AddBloc" TagPrefix="object1" %>
so maybe theres something wrong with those two lines. I wouldn't know I'm still learning asp.net myself. Maybe the fact that the tagprefix is the same confuses the server?
Another weird thing is that the exact same code was on a different folder before, and never made that error (it had been running for a long while). It's when we moved it to change the folder's name that it started acting up. It was never fully compiled,
either, and debugging has always been set on true.
I don't know if that info can help. To me it seems like some cache clearing error of some kind (like, the normal assembly name would be erased over time by some unknown action and the application would try to create or find another and would simply fail).
Maybe I'm completely wrong. I just hope we can find a way to fix this, because it's getting incredibly annoying, and we're supposed to put one of our prototypes up on a public server soon, and we dont want that happening when its there.
Feb 28, 2007 01:32 PM|LINK
I just experienced this problem to day ... and solved it by setting:
Mar 08, 2007 02:09 PM|LINK
We have a solution that solves the problem (none of solutions above doesn't solve that problem not even MS HotFix).
Can some from Microsoft team just tell us if giving NETWORK SERVICE write permissions on whole project is not a security issue.
After that we will share our solution with others.
Mar 12, 2007 06:50 PM|LINK
I reproduce this error up to a half-dozen times a day on a development server (XP Pro SP2, IIS6, Net 2.0.50727, VS2005 SP1, MS SQL).
I'm at the stage where I'm doing refinement passes using VS2005. Typical scenario is that I make a code change or two in VS2005, then do a refresh on my page to see what happens (I do not use VS2005's GUI-based editor). It usually recompiles fine, but
I frequently get the "Could not load ...".
Virtually all my pages contain user controls that contain user controls (that contain user controls ...), and 95% of my work is on these controls. My usual method of recovery involves a low-level VB file that inherits from Page, and from which all my other
pages eventually inherit. I "touch" this file, triggering a JIT recompile on the next refresh. The page always comes up nicely afterwards. (When this problem happens in production, I touch the same VB file or execute a batch file that runs aspnet_compile
If there's anything important I might add to this discussion it's that I've noticed that I never get the problem two times in a row, despite how often I get it. In fact, after correcting the problem, I can pretty much count on being problem-free for a while.
I'm not sure of that time-span, but it's perhaps 15 minutes to a couple of hours.
Another tendency, at least on my dev machine, is that I think I can refresh the page all day without a problem until I get to a JIT compile. It's the compile itself that seems to be the culprit, or more insidiously, the compiler is perhaps the victim of a
different intermittent process (cache cleanup?) that doesn't know how to play well with others.
Because of the nature of the code, I often make changes to multiple user controls in both sibling and parent-child relationships before refreshing the page, and child controls often have multiple parents. It's an organized rats nest. If asked to hazard
a guess, my feeling is that I have a control1 that references a control2, and the former compiles fine, but later, something perhaps erroneously triggers control2 to unexpectedly (at least to control1) to recompile and control1 ends up with the dangling file
reference we all know and love.
I'll start paying more attention to when this problem occurs now that I see it's "not just me" and post anything I find with a little surety behind it.
Mar 14, 2007 07:42 PM|LINK
After a long period of not experiencing this error in production or development, it finally happened and I was able to send a dump file to Microsoft. I had opened a support case and was working with a technical rep to figure out what was going on. I sent
her the files and she was able to respond within a day.
This is the response I received:
"It seems there’s a timing issue when app domains shutdown and then startup where the appdomain deletes a file from temp asp.net files folder that the new app domain just created.
As mentioned, we hope to have a fix for this shortly – but one workaround that has worked for the other case was to increase the numRecompilesBeforeAppRestart to 50 (default is 15). This is in the web.config
for the application.
So, to sum up, this is a temporary workaround that should work for most. In the meantime, MS is testing a hotfix with several customers right now so we may see it released but they cannot give a firm date on that yet.
I hope this helps.
Mar 15, 2007 12:23 AM|LINK
But how is this parameter change supposed to help us? Does it merely reduce the frequency?
Thanks for staying with this and reporting back. You're the Man!
Mar 15, 2007 12:31 PM|LINK
But how is this parameter change supposed to help us? Does it merely reduce the frequency?
That is correct. It reduces the frequency. In my case, since it happens very infrequently, this value means I'll likely never see it again with or without a hotfix. For others who see this exception daily, the value may need to be increased.
I am not sure how it affects performance to increase the value, so take that into your own considerations.
When my tech rep lets me know about the hotfix, I'll post it on this thread.
Mar 15, 2007 01:02 PM|LINK
Actually, I did a little google search on this specific parameter, and stumbled on an article that explains a bit of how the application compiles depending on the debug mode. It might help you understand what it does to read it (and it's a nice knowledge
to have, as well)
For the lazy people who don't feel like reading it. When you "restart" your application (IE by changing the master page, the web.config file or other files that forces recompilation) theres a specific number of times you can actually make changes on controls
and pages before it kinda recompiles on its own again. During the mean time (the 15 changes by default) everytime a file is changed, it creates a new dll for the specific file depending on the debug type. So the more controls there are on your webpage and
so on, the more files are created. After the 15 changes limit, all the "old" assemblies are deleted, and the pages are recompiled. At times, one specific control's assembly might not be recreated, as its part of another folder, perhaps, maybe, so it will try
to reach the old assembly that's not there anymore and that's what causes the problem. Forcing a recompiling will solve the problem, as the assemblies will be recreated. It happens less often when debug is set to false because the files are compiled in a batch
instead of one by one, so it is less likely that a reference will be lost. And it happens less often when your application restarts less often (the 50 times). But this will fill up your compiling folder (which I have no idea where it would be) with a lot
of useless dlls, and thus might reduce performance. Of course, while you're developping, you often make changes, and the limit is easily reached (especially at 15... I think I make at least 50 changes/hour to files in a normal day of work.) and the less you
work on files that force application restart, the more often those errors will happen.
Now, why sometimes this happens on production servers where there are only visitors and no file changes... I'm not too sure what's going on. Anyway, that's my understanding of the problem, I can be wrong, I probably I'm off on my interpretation in a few
places, but I think I got the basics down, and the article is a very interesting read in itself for understanding where this problem comes from.
Hope I answered some questions [:$]
Mar 17, 2007 01:33 AM|LINK
Thanks for the info, Krakador. It explains a lot.
FTR, I changed my count to 50 yesterday and went all day without a problem. Croaked once today, though, so I think I'm still looking for that fix.
Mar 21, 2007 08:09 PM|LINK
I have experienced this problem a little bit as well, and here is what I can tell:
I have a user control that is called by the master page (fairly top level UC), but inside it, there is another UC nested there... I had added a Literal onto the top level UC, and immediately started seeing this error. I edited the web.config, etc. to force
a recompile-- nothing. I erased the temp files under c:/windows/MS.net... still nothing. Finally, I simply removed that Literal, and immediately the problem went away.
Here is the weird part:
I immediately re-added that Literal again to try and replicate the error, but this time it worked exactly correct. I didnt even do anything except hit "undo" on the 2 lines I had erased to make the problem go away. So there was literally NO DIFFERENCE whatsoever
in the code between the error being generated and the error not being generated, except that I had to backtrack to make it go away before I could progress.
I don't know if this will be of any value whatsoever, but I just thought I'd share since it was really weird.