I feel like the work Miguel De Icaza is and has been doing around C# platform interop is some of the most challenging and beneficial work happening in the FOSS. It is pretty startling what he and his team have accomplished in such a short period of time, in some ways actually hearing where the C# language is going from Microsoft and getting out ahead of the curve.
This is incredible work. Props to Miguel & co. for pulling this off; it's just a damn shame that Microsoft just can't seem to decide where they want to go with C#/.NET.
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.
The only "safe" .NET framework to use for development is version 2.0. Thankfully, with VS2010 you can compile C# 4.0 (the language version) against the .NET 2.0 Framework.
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.
I've never had to deal with framework version problems, as our software is for internal use only, but I can imagine figuring out what to target would be painful.
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.
Don't see how the relevance or presence of XAML/WPF affects the use of the rest of the framework and the BCL, and I would be shocked to hear about your backwards compatibility issues between running compiled assemblies on different CLR versions. Also, I think you mean .NET 4.5 in Windows 8 - .NET 4.0 was released over a year and a half ago, and runs most legacy applications perfectly well.
.NET 4.5 is from the .NET 4 family - and it does not "run most legacy applications perfectly well" as it'll only run .NET 4 and .NET 4.5 assemblies as-is (though workarounds do exist to force it load .NET 2+ apps, though with no guarantees).
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.
To be clear, Windows 8 desktop mode will almost certainly support .NET 2.0 apps; it just won't ship with that version of the CLR.
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.
It won't ship with (out of the box) support for .NET 3.5 apps either - and that shipped for the first time with Windows 7.
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 don't agree with the "tottering on the edge of oblivion" line, but ComputerGuru does make an excellent point about targeting runtimes beyond 2.0. When working on the server/ASP.Net, you are fairly safe using 3.5/4.0, but when doing Windows applications its very painful. The 2.0 runtime was fairly compact and easy to redistribute. 3.5 was a beast in comparison! Even the newer "client profile" versions of the runtime are still painful when you want to build a compact installer for non-technical end users.
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.
Being able to sanely bridge to C++ code from any language is a huge deal, Miguel and the rest of the folks at Xamarin are tackling some very difficult problems and succeeding.
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.
18 comments
[ 5.3 ms ] story [ 42.3 ms ] threadWhile 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.
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.