CXXI: Bridging the C++ and C# worlds.
tirania.org
tirania.org
Especially for the games industry which Xamarin is really interested in developing for (i.e. Mono as your game's scripting engine while the core renderer is in C++), simple binding to C++ will be awesome.
While the C# language has become one of the very best (as a language not a framework) with version 4, .NET seems to be tottering on the edge of oblivion.
Since 2.0, Microsoft has engaged in random "experiments" with the .NET framework, taking it in random directions then killing those projects off and starting again. XAML/WPF is the best example, where Microsoft begged the world to stop using System.Windows.Forms (standard Windows widgets/controls) and to switch over to vector-based XAML/WPF where each project needs a developer + a completely separate designer to have any chance of making a half-decent looking project.
Some developers (myself included) never made the switch - good call, because today WPF is dead thanks to a) it was a stupid call in the first place and b) it was very badly implemented, introducing incredible lag, requiring lots of memory, and generally resulting in a bad user experience.
Their other problem is with distribution/versioning. New versions of .NET tend to be released a month or so after new versions of Windows - meaning you'll never get Windows shipping out of the box with the latest version of .NET. While backwards compatibility is preserved (i.e. .NET 3.5 will run .NET 2.0 apps), it's very subtly broken as you'll find that a .NET 2.0 app compiled with VS2010 will actually not run on an actual .NET 2.0 distribution because no one bothered to check if the same method signatures existed for certain functions and whatnot.
Now the new challenge is Windows 8: first, Microsoft seems to be leaving .NET entirely pushing their new Metro toolkit and WinRT as the preferred routes of development. IMHO this will be a complete failure as it leaves behind both the .NET developers AND the traditional, hard-core WIN32 developers in an attempt at a "clean slate" that no one actually wants.
Even worse, .NET 4.0 in Windows 8 breaks all that backwards compatibility. Out of the box, it will not run apps compiled for .NET 3.5 and below - all .NET apps need to be recompiled to run on .NET 4, or the user will need to install .NET 3.5.
Footnote: Unfortunately, Microsoft's other good feature for .NET, Linq, was introduced in v3.5 of the .NET Framework. If you're targeting Framework 2.0, this is the one good feature you'll miss out on.
You don't need to have a separate designer to take advantage of XAML, I've written several applications doing both XAML and C# myself. It does make it much easier to have a non-programmer work on the UI.
Metro and WinRT have .NET bindings, and most of the samples I've seen are written in C#. It prohibits use of System.Windows.Forms for the same reason that you can't use the Win32 UI libraries, but the rest of the framework is available. Also, the Metro UI authoring is done using XAML.
None of this is to say that I love everything Microsoft does. I'm sick of their sandbox, and the projects I do for fun are all Linux / HTML or Android-based.
As for the "shocking" backwards compatibility issues - they're very well documented. Compiling against .NET 2.0 in VS2010 gives you access to certain methods and overloads that were not present in the initial .NET 2.0 release, but were added in SP2 and SP3. Which is cool... What's not cool is that a) there is no official list of methods added between the SPs to the best of my knowledge (but I really could be wrong here!), and more importantly b) the resulting application which actually requires .NET 2.0 SP2/3 will run on .NET 2.0 RTM (for example), and you'll have ZERO indication that it's broken until during runtime when you try to call a particular method or overload that was not present in the version of the framework you're on, when you'll get some generic exception instead. Good luck figuring that one out from the anonymous crash dumps you'll receive by email.
A proper approach would have been the option to select which SP of the Framework you wish to compile against or at the very least, generate warnings during compile that your use of function X will CRASH on .NET 2.0 SP1, for example. That, and proper detection of out-of-date .NET runtimes (a la SxS - which while a real PITA at least makes sense) instead of silent, nasty runtime crashes when using mismatching versions.
Off the top of my head, I recall that the Auto/Manual reset event classes have either methods or overloads that were modified between SPs.
By the time that Win8 ships, .NET 2.0 will be six years old - do you really expect them to support it in the latest OS forever?
For instance, Windows 8 still ships their VB6 runtime from 1998.
Disclaimer: I work at Microsoft (and yes, I know you did too), but this claim is based on my perceptions and should not be considered a statement of fact.
As far as needing a designer goes - perhaps not, but in comparison to SWF, certainly. With SWF, you dragged-and-dropped standard Windows controls we all know and love to a form, did the bindings to event handlers, and that was the end of it.
XAML places a much larger burden on the developer. Sure, it gives you the ability to create more flexible layouts, but at a tremendous cost. You have to actively design your application's user interface from a much, much lower level up. .NET's biggest draw was the RAD factor, but with XAML/WPF, a lot of that for utilites and other smaller applications with GUIs was left behind. There's certainly nothing RAD-esque about WPF.
"Windows Media Center will also return to Windows 8 beta alongside the typical Windows games, DVD creator and .NET 3.5. All were missing from the developer preview, made available in September."
I really wish the latest runtime was aggressively pushed by Windows Update, but since it is not you are always in a position where you choose between a painful install process or a giant bloated installer. Not fun. Glad to be back in the web facing + internal tools side of .Net at my job now for this exact reason.