I've never seen this error message before. Saw it yesterday as I was re-theming dasBlog for this blog o' mine (coming soon ... I'm almost done). I was working on adding some extenders from the Ajax Control Toolkit (if you not seen this - and I'd be surprised if you haven't - it's a collection of super-cool extenders for ASP.NET Ajax) and this fun little message came up.
Here's what I was doing ... I have a hierarchical list that I'm adding in the side menu. It'll have the typical menu header, but to conserve space, I'm using the Collapsible Panel Extender to allow certain child sections to be expanded and collapsed. I first tried to do this with Data Binding (the easy way out), but the whole TargetControlID thing didn't work too well in that scenario. I'm sure that, with enough contortions, I could make it work but that'd defeat the entire purpose. So ... rather than do that, I just added all of the controls in code. Tedious, but not very difficult. Then, when I ran this, I got the message above - "Operation could destabilize the runtime."
"Hmmm", I thought to myself, "why on earth would this destabilize the runtime." Well ... not quite like that ... there were some additional words in there that aren't really appropriate for this blog. It had already been a long, already frustrating day (for other reasons), my brain hurt and I was now pretty frustrated. If I had hair, I would have been pulling it out (a very good reason to shave your head, by the way). I tried to remove the lines that the stack trace was pointing to, only to continue to get the error.
And yet, there was a certain pride, I suppose. Must be doing something pretty hardcore to destabilize the runtime, eh?
Actually, that wasn't the case. Of course, it would have been quicker and less frustrating had I been more methodical and logical about debugging the problem rather than just commenting a line of code and then refreshing the page in IE. But it's funny the dumb things that one does (at times) when the frustration level goes over a certain point. Well, not really funny at the time.
When I finally did get methodical about it, I found that the error really wasn't at the line in the stack trace. Why the stack trace pointed to the wrong line is a mystery, but one that will, for the time being, remain so as I really don't care to figure out why - it doesn't matter anyway. When I finally went to debug mode (attaching the VS debugger), the error occurred as soon as it entered the function that was building the controls ... the stack trace in the ASP.NET error page was pointing to one of the lines in this method, several lines into the method. Even more interesting was the exception detail: "Make sure your application is not loading two conflicting versions of a class library." Huh? How on earth is this happening? And what library is being loaded more than once with a different version? These mysteries, unlike the stack trace issue, did matter and they mattered quite a bit.
Now, keep in mind that dasBlog was done with ASP.NET 2.0 and Framework 2.0. I had upgraded it to Framework 3.5.
I dug around in my web.config file trying to see what was going on ... but there was nothing in the references that pointed to the issue. Still curious, I fired up the Fusion Log Viewer to get a better idea of what libraries were being loaded.
It turned out that the Ajax Control Toolkit was, for some reason, trying to load the original version of ASP.NET Ajax. I'm not sure why ... I had the 3.5 version of the toolkit referenced ... but it was. And the Ajax library 3.5 was already loaded - it was referenced in my web.config file specifically by version. Hence the error.
Further digging around in the web.config, I found that many (well, almost all) of the web.config settings for ASP.NET Ajax library weren't in there. This, naturally, presented something of a problem. So I methodically added them in and presto! ... it all worked. It turns out that the critical setting was the assembly redirection for ASP.NET Ajax 1.x. It wasn't in there ... so the 1.x library wasn't being replaced with the 3.5 version.
One note: this was the version of the toolkit 3.0.11119.0, released in November '07. The current version of the toolkit is 3.0.20229. I've not upgraded to that yet (I will before it's released) so that may fix the issue. I did look in the source for 3.0.11119.0 and saw that it does reference the 3.5 version of Ajax ... so exactly what's going on, I don't know. Still, regardless of any of this, the assembly redirection element in the web.config really needs to be there anyway.