Friday, January 06, 2006
« Dislike all those extra DLLs? Ditch them... | Main | Two things... »
ASP.NET Development Server assembly load issues

As I’m working on the next edition of my Expert VB/C# Business Objects books I’m building both a Web Forms and Web Services interface. And I’m running into issues with the ASP.NET Development Server provided with Visual Studio 2005. This web server is often referred to as the VS Host.

 

The issue is with assembly loading. Apparently the VS Host has difficulties loading assemblies at times, which causes issues.

 

For instance, you can’t test a custom membership provider if it is in a separate assembly that is referenced by your web site – that causes an assembly load exception.

 

In my particular case the problem I’m having is that I put a custom IPrincipal object on the thread and HttpContext. That works great, but at some point VS Host apparently switches to some other internal AppDomain – triggering an attempt to serialize and deserialize that principal object. The result? BOOM!

 

Again, an assembly load exception – this time because the attempt to deserialize the principal object into that other mysterious AppDomain fails…

 

All my usual tricks have failed. I’ve tried clearing the principal from the thread and HttpContext before the page processing is complete. No dice. I’ve tried handling the AppDomain event that is raised when an assembly can’t be found. No dice (which isn’t a surprise, since it isn’t MY AppDomain that’s having the problem).

 

In the end, the VS Host appears to be useless for any work where you are using custom principal or custom membership provider classes. In a casual conversation on this topic a friend of mine suggested that perhaps VS Host was for prototypes and hobbyists; and I think he was right. Real web development still must be done with IIS only...

Microsoft .NET
Friday, January 06, 2006 11:43:45 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [8]  |  Related posts:
VS10 and SQL Express frustration
Silverlight 6 doesn’t matter
WinRT and business apps
WinRT and .NET
Windows Server AppFabric and WCF monitoring
Minneapolis PDC, Code Mastery and more!
Friday, January 06, 2006 11:59:11 AM (Central Standard Time, UTC-06:00)
Interesting. We are having the same problem under the same conditions and were thinking that it was something strange we were doing. We also gave up and went back to using IIS. Hopefully we'll see a fix for it some day!
Joel Lyons
Saturday, January 07, 2006 8:12:49 AM (Central Standard Time, UTC-06:00)
At a glance, I wonder if this VS Host behavior is related to some less-common IIS behavior, usually exhibited only under load. See this article:

http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html

In short, ASP.NET Requests (at least in .NET 1.1) are apparently thread-mobile, mid-request. There's no mention of moving accross AppDomains, though.
James Koch
Saturday, January 07, 2006 9:26:32 AM (Central Standard Time, UTC-06:00)
Well if he's right and the thread state is being serialized then that could be the problem - though I don't think so. Because even if the thread's state was serialized and then that state was deserialized onto a different thread in the same AppDomain then the types to deserialize should be available and/or my handling of the assebmly resolve event would have worked.
Rockford Lhotka
Monday, January 09, 2006 1:36:07 PM (Central Standard Time, UTC-06:00)
We are using CSLA.NET 1.50 with custom principals running under VS 2003 and Cassini without any problems so far. Isn't the VS Host in 2005 based on Cassini?
Scott Kuhl
Friday, January 13, 2006 10:12:29 PM (Central Standard Time, UTC-06:00)
Rocky -- can you send me more details on the exception, and ideally an easy repro to show the problem?

You shouldn't be having this problem, so I'm not entirely sure what is going on.

Thanks,

Scott
scottgu
Thursday, January 19, 2006 3:23:22 PM (Central Standard Time, UTC-06:00)
I am having a very similar problem with VS Host. I have created a plugin architecture where assemblies are loaded at runtime as needed into the asp.net appdomain from a directory located under bin – i.e. /bin/plugins/. Objects that are defined within the plugin assemblies get added to the viewstate at certain times in the usage of the application. In VS Host after every postback I get errors such that the viewstate is corrupted. Following through all the stack dumps and internal exceptions, the root of the problem is that Asp.Net is failing to find the plugin assembly that was loaded into the appdomain.

A quick fix for this was to put the bin/plugins/ inside the assembly search path in the web.config.

<runtime>
<assemblyBinding>
<probing privatePath=".\bin\plugins\" />
</assemblyBinding>
</runtime>

It then finds the assembly and reloads it as needed, which unfortunately appears to be very often.

This mitigates the development problems for the most part. The question is though, why can’t the AppDomain find the already loaded assemblies? Is the AppDomain being thrown out in VS Host on every postback? This is what appears to be happening at first glance.
evan
Monday, January 23, 2006 5:36:42 AM (Central Standard Time, UTC-06:00)
Alec Baldwin SNL Whether as Scout Master, French Teacher or "Schwetty Balls" Tough Guy, Alec Baldwin is undoubtedly one of SNL's funniest hosts. Get Alec Baldwin SNL at http://www.saturdaynightlivedvd.com/baldwin/index.html
Alec Baldwin SNL
Tuesday, February 07, 2006 10:23:35 AM (Central Standard Time, UTC-06:00)
If you create an AssemblyManager host you can specify that these assemblies youn need are loaded as Domain Neutral. This has performance drawback but is what you are trying to accomplish.

its relatively easy to do if you know c++
Nick
Comments are closed.