I know this is getting a lot of fanfare but let us apply four major costly problems I'm having with the CLR/Framework at the moment:<p>1. Microsoft.Build.Tasks (the bit that has been screwing with me all day) contains static sealed classes with nothing in them. I thought this was a reference source rather than a source of empty interfaces and empty implementations? Still having to resort to reflector to find out what is going on. Problem not solved.<p>2. So, ReaderWriterLockSlim has a bug in it with respect to low CPU allocation in virtual machines where 20 concurrent threads accessing a locked object at the point of write cause the spin lock in the implementation to thrash and up blows a race condition taking out the process. I can actually see where the bug is now. Where do I submit this bug, bear in mind I can actually recreate it? I phoned up our MSDN rep - they said raise it on Connect. There isn't a place for it on Connect. Phone up generic paid support, three levels of technical staff bounce me around for a week. as a PAID UP GOLD PARTNER, this sucks. If you open your source, track bugs openly too. Problem not solved.<p>3. This is only the core framework. We really need the entire lot including all dependencies and external tools. There aren't any symbols on symbol server or this for VSTO or Sharepoint for example? What we do get is another black box somewhere in the system that we can't inspect or poke inside even though it's a wrapper for a COM API or a product API. Problem not solved.<p>4. Does Rosyln/next MSBuild support parallel compilation? Being tied to a single compilation core on a VS2013 build means we have 8 core Xeons sitting there doing nothing. Our only hope of speeding this up is cranking up to high end i7 to get one core with crazy integer performance. 20 minute sit down compiles are too much these days. <a href="http://xkcd.com/303/" rel="nofollow">http://xkcd.com/303/</a><p>I understand this is progress and Roslyn is cool and all that, but what does it deliver for every day users of the CLR/Framework? It doesn't really make our day much easier. In fact stuff that really improves developers' lives has stopped appearing completely and instead we get tedious reengineering projects and new features designed only to lock us further into the system (VS online+sign in anyone?)<p>Also how does this compare to say LLVM/Clang?<p>I imagine this semantic compilation stuff will make some static analysis stuff easier and stamp on the toes of Coverity etc but that's about it.<p>Edit: sorry if this is purely a content-free rant and unpopular but after 12 years of this crap from Microsoft, I want to see new wheels, not the same ones reinvented and remarketed. Developers are lapping up this crap constantly as if it's as good as it gets. We need some REAL CHANGE towards openness and consistency and to ask the community and users what they want rather than telling us what we need.
Roslyn changes are starting to kick in - 2014/15 should be pretty exciting!<p>"This means that folks like the Mono team could look at this Reference Source and not have to gouge their eyes out afterwards. "<p>Very reassuring as well.
It looks like there are still big censored parts:
<a href="http://referencesource-beta.microsoft.com/#PresentationFramework/src/Framework/System/Windows/Window.cs#461" rel="nofollow">http://referencesource-beta.microsoft.com/#PresentationFrame...</a><p>One of the first things I had to do for my last job was subclass Window to support custom borders (Zune Player/VS2012/Office 2013 style.) I took a peek at the reference source, and I couldn't help but think the missing bits were the juicy bits, workarounds for window manager bugs or insights into how it does things.