Jack Gudenkauf - .Net 3.5 for ISVs

I don't understand why the technology demonstrated is such a big deal. As I understand it, WPF uses a kind of X11 style protocol for control rendering, so all it takes to allow controls to render from different app domains is to provide a channel for that protocol to cross. It's very useful, but not staggering IMO.

Now the stuff with integrating winforms controls with WPF, all I can say is: ugh, I'm glad I didn't have to write that.  All this interop stuff is hard, messy work that Microsoft doesn't get nearly enough credit for. The Java world just says throw away everything you wrote before but Microsoft always tries to help people come into the new platform bit by bit.

Another thing, which is probably not Jack's area, but I might as well mention it here. You mention in the video that one of the advantages about being able to run GUI plugins in different app-domains is that you can unload the plugin to recover memory and other resources. WHat I want to know is when is .NET going to get the ability to unload assemblies and garbage-collect the memory allocated for the code? I know it's a hard problem, but Java has been able to do this for many years and it should be considered an embarassment that .NET still cannot. While AppDomains serve many purposes, including allowing for code to be unloaded, you often don't need the isolation of an AppDomain and don't want the marshalling overhead of communicating across AppDomains, but you do want to be able to load, execute and then discard code.