Blizzard of great new stuff for today, summarized nicely by ScottGu.
The new Parallel FX stuff is really quite cool. It’s a cliche to say that the number of CPUs in a typical machine is increasing while each individual CPU is not actually faster. But it’s great to see Joe Duffy release Parallel FX and PLINQ to to actually address the challenge.
All very cool can’t wait till next week for ASP.NET MVC.
1 Comment | 
Ajax, Architecture, code, Development, finance, Microsoft, ScottGu, SilverLight, Visual Studio, Web, WPF, xml | 
Permalink
Posted by Jan Bannister
I recently came apon one of my recurring peeves: XmlSerializer. It’s one of those classes that just bits you again and again. It has a number of annoying behaviours but the worse has to be it propensity to write to disk. Why? Why, of all classes, would you choose XmlSerializer to perform file IO?
It’s lunacy since the class is typically used in scenarios where you’re in executing from inside a sandbox, like XBAP, Silverlight or other partial trust settings. And then WHAMO your auto generated SOAP proxy… writes to disk!
It just makes no sense. However I know why XmlSerializer writes to disk; because it uses Reflection. Which ‘emits’ a dynamic assembly , again, to disk. Which in itself is further lunacy, is it not? I’m dynamically building an object, I know, lets write to disk.
.Net is capable of loading Assemblies from MemoryStreams, I’ve done it, so why default to writing to disk? It’s like the bank teller going to The Vault to get you a fiver: time-consuming and insecure.
Has anyone got a defence for XmlSerializer? … It better be sturdy 
3 Comments | Architecture, code, Development, Microsoft, xml | Permalink
Posted by Jan Bannister
