<bump>

Anyone from Microsoft have any input to this problem?

<bump/>

I don't think there a bug there. Type loading exception may happen when application tries to load conflicting assemblies, such as two versions of System.Web.Extensions (1.0.x and 3.5.x) into the same process. Careful inspection of web.config file may help.

 I've been having the exact same issue with one of my projects and found a solution.  My machine-level web.config located in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG had the following line:

 <add tagPrefix="asp" namespace="System.Web.UI.WebControls.WebParts" assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

 Removing it fixes the error.  This line was apparently causing a conflict since this causes the framework to first look in the System.Web.UI.WebControls.WebParts namespace for the web control, which causes a TypeLoadException.  It then finds the control in the System.Web.UI.WebControls namespace and continues executing.

 Hope this helps.

Not sure if anyone is still having this problem....

Here's a fairly informative and helpful post I found on this issue
http://forums.msdn.microsoft.com/en-US/netfxbcl/thread/da1eedcd-50d3-46b0-bfd8-f3c840d72b55

@ptcmac - this may be the post you were referring to, which mentions the source code responsible for this error:
http://weblogs.asp.net/okloeten/archive/2008/04/17/6107382.aspx

As you point out, exceptions should not be used for flow control and someone was being naughty/lazy when they wrote this code (they should have made the effort to use a bit of reflection on each assembly in the control tag list to figure out where each type lives, then cache this information to improve performance by reducing repeated reflection usage). It seems like the list of control tags are loaded into a multi-hash or something internally, which is why these errors sometimes occur and sometimes don't - depends on the order in which the control tag list is enumerated.

Tess Ferrandez has a good debugging post mentioning this problem here:
http://blogs.msdn.com/tess/archive/2008/05/14/asp-net-performance-issue-large-number-of-application-restarts-due-to-virus-scanning.aspx

Unfortunately, Tess disregards the System.TypeLoadException as "benign" and goes on to her main point of virus scanners causing ASP.NET application restarts; however, hopefully her debugging investigation may lend some additional insight into this problem.

So, the bottom line appears to be that we have to live with these "benign" (performance-degrading) exceptions until someone in MS fixes the code. In the meanwhile, the *only* way to get around the problem is to *never* use the "asp:" tag prefix, but instead register your own unique tag prefixes in the  system.web->pages->controls section of your web.config and make sure you use those tag prefixes in *all* your code. Bit of a PITA, if you ask me.

PhilipTheDuck, you are quite correct.  That is one of the snippets of code I was referring to.  I believe there is at least one other that does something similar but traps a couple more similar exceptions, including the ubiqutious TypeLoadException.

Fortunately, however, I may have found a solution that does not require my changing something so drastic as the asp: namespace on all of my tags.  Currently my solution has 77 projects and more than 2800 files in it.  Most of which do not contain markup, but still, a significant number do.  It also seemed VERY wrong to me that microsoft would create and distribute both ASPNET and VS in such as way as to be completely wrong by default; the asp prefix is the default.  And finally, changing the namespace prefix would work for static markup but does not address the problem of dynamically added controls.

Anyway, as I said, I seemed to have solved my problem.  My solution, unbelievably, was to reset my VS2008 configuration settings to the default.  I know this sounds unbelievable but I am a careful and organized researcher and troubleshooter.  I was clearly able to reproduce the problem multiple times in multiple ways, and then, when I reset my VS config settings (on a whim), without doing anything else, I am no longer able to reproduce the problem, no matter what I do. 

Here was my process...

1. I installed a new OOTB version of VS2008 in a VM.  This was a default install.
2. I tested a simple website by adding a Login control and a Literal control to the default default.aspx.  I was unable to reproduce the problem.
3. Based upon Mikhail's advice from an earlier post in this thread, I spent a couple hours searching for and comparing all the .configs on the VM against the .configs on my development installation.  I could not find anything that was dissimilar.  In fact, except for the local web.config, all the config files (machine.config, machine web.config, etc., ...) were line for line identical.  I could not find anything in the local web.configs that seemed to cause the problem.
4. I copied all of my solution files to the VM and set the VM up to run the solution.  This involved installing a couple of dependencies, such as WSE, and configuring IIS.  The VM was WinXPPro SP2, BTW...  When I ran the solution, I was unable to reproduce the problem.  This was exactly the same code with exactly the same web.config.
5. While sitting in despair, wondering what to look at next, how much more research I was going to have to do to solve this problem, and whether or not the time spent wasted on researching the problem would be saved by eliminating the wasted time waiting for the compile and load to complete with the problem, I noticed that there were a couple things missing in my development VS environment that were in the fresh install environment on the VM.  These were trivial things - like additional options on the debug/exceptions dialog - that did not have anything to do with the problem at hand.  I attributed these minor differences to the settings collection I had chosen on first run of my development VS install.  So, I decided to reset my config settings.
6. Again - being a careful and organized researcher and troubleshooter <grin> - I didn't want to make any changes to my development env without making sure I could still reproduce the problem, I tested again.  Indeed, I was still able to immediately reproduce the problem in my development environment.
7. Now, I went ahead and reset my configuration settings collection using "Tools/Import and Export Settings...".  I first saved (exported) my current settings collection, and then reset to (imported) the default "Visual Web Developer" settings.
8. I immediately tested again.  To my great surprise, I was no longer able to reproduce the problem.  I tried again, several times, using several different methods that had reliably reproduced the problem before and was unable to reproduce the problem.  Problem solved.

Once I realized the TypeLoadException problem was gone. I compared my old settings collection file I had saved to my new settings.  The BIG thing I found was that I had, over time, deleted and rebuilt a number of items (primarily ACT controls) from my VS toolbox.  My guess is that something in the way these items had been deleted and then rebuilt was causing the TypeLoadException.  Perhaps by somehow changing the default namespace or load order.

It also seems to me that there are many manifestations of this particular problem.  Given the length of this thread and the number of hits has received, it is also a common problem.  My solution may only solve one of the manifestations of the problem.

Anyhow, the final result of this rather long-winded and verbose commentary, is that resetting my VS config settings did the trick for me.  What used to take nearly a minute to build, JIT, and load now happens in a few seconds.  And, thankfully, I didn't have to do anything like make special modifications to my web.config or use a special tag prefix.

MAC