The .NET/Mono Framework has never offered a single, unified stack. Even in the early days there were two runtime versions, the .NET Framework and the .NET Compact Framework. Over the years Microsoft and Novell added new versions to cover Linux, OS X, and mobile devices. With the introduction of Windows 8 and Visual Studio 11 we can expect one, maybe two more. In an attempt to clear up some of the confusion this article reintroduces all of the major profiles and many of the lessor know ones.
Terminology
The term “runtime version” refers to different implementations of the Common Language Runtime. With the exception of MonoTouch, all runtime versions use the same format for executables and libraries but are not necessarily compatible. Profiles generally refer to true subsets of a given runtime version but as you’ll see that isn’t always the case.
A “targeting pack” is essentially the package used by Visual Studio to support for various combinations of runtimes and profiles. The complete list of targeting packs for Visual Studio 11 is available on MSDN.
.NET Framework
The flagship of the stack is still simply called the “.NET Framework”. While the formal title of the current version is “Microsoft .NET Framework 4 Platform Update 1”, it is also referred to as version 4.0.1, though the files it contains are clearly stamped “4.0.30319.17202”.
The .NET Framework runs on Windows only and can be used for:
- Console applications
- ASP.NET
- WinForms/WPF Applications
- Windows Services
- PowerShell cmdlets
- COM Components (e.g. plug-ins for applications such as Office)
- SQL Server Extensions
One can also create .NET applications that run in Internet Explorer, but virtually no one did, even before the introduction of Silverlight.
.NET Framework Client Profile
The .NET Framework Client Profile is a true subset of the .NET Framework which omits the assemblies used for server-side development. The theory is that developers who limit themselves to this profile can offer users smaller downloads.
The Client Profile does not appear to be widely used. The fundamental problem is a matter of timing; it was designed to solve the problem of dial-up bandwidth but was released after broadband access became widely available. Developers should only consider using it if the following is true:
- Download sizes are a major concern for first-time users. (Upgrades will not require re-downloading .NET itself.)
- Silverlight is not a viable option
- None of the “server-side” assemblies are needed
The last requirement in our checklist is much harder than it may seem. For example, most applications interact with HTML or HTTP in some way. Common uses include HTML-based help files and web service calls for downloading data needed by the application, or the generation of emails. While the Client Profile can certainly handle these tasks, one often needs the HtmlEncode and UrlEncode methods. These are part of System.Web, an assembly that is only included in the full version of .NET. While it isn’t necessarily hard to find or create an alternative implementation for these methods it is rarely worth the effort.
Mono
Mono is an open source implementation of the Common Language Runtime and is largely compatible with the .NET Framework. The project claims that Mono supports “Everything in .NET 4.0 except WPF, EntityFramework and WF, limited WCF.” A compatibility list is available as well as a tool to check assemblies against the Mono class library and to warn developers about potential problems.
The Mono runtime primarily targets Windows, OS X, and openSUSE Linux. Debian and Ubuntu Linux are supported by their distributions. Mono can be used for:
- Console applications
- ASP.NET
- Cross-platform Applications (via WinForms, Gtk#, or wxNet )
- Mac AppStore Applications (via MonoMac)
- Linux/KDE Applications (via Qyoto)
- Windows Services
One would generally not create extensions (COM, PowerShell, SQL Server) using Mono because the host environment would preemptively load the .NET runtime instead of Mono.
Browser-Based Profiles: Silverlight/Moonlight
Silverlight is a scaled down version of the .NET Framework designed to run in the browser. It includes a subset of WCF for accessing server-side resources and the GUI is a variant of .NET’s Windows Presentation Foundation. Silverlight is not a true subset of WPF and UI logic cannot be shared between the two. Silverlight runs on Windows and OS X with the IE, Firefox, Chrome, and Safari browsers.
Moonlight is the open source, Mono-based variant of Silverlight. Though it supports most of Silverlight’s capabilities, it lacks the DRM support necessary to run the popular Netflix service. It runs as a plugin for Firefox and Chrome and is distributed for SUSE Linux Enterprise Desktop 11, openSUSE 11.x, Ubuntu 9.10, and Fedora 12.
Moonlight, and later versions of Silverlight, additionally support running applications outside of the browser. Silverlight 4 added the ability to access COM components in Windows and version 5 will add support for accessing Win32 libraries via p/invoke. Similar functionality is not being offered for OS X or Linux.
.NET Compact Framework
The .NET Framework was always intended to be a cross-platform development. At the same time the first version was created for Windows running on x86 compatible machines, a lighter weight version called the .NET Compact Framework was created for smaller devices, including hand-held computers, smart phones, kiosks, and devices such as GPS-based navigation systems.
Visual Studio no longer supports development directly against the .NET Compact Framework. While one can occasionally find a device still using it, developers are increasingly turning to Android for that role.
XNA
Based on the .Net Compact Framework, the XNA framework runs on Windows and Xbox 360. It is only used for game development and doesn’t offer any of the GUI or server-side libraries from the full version of .NET. A special version of Visual Studio known as XNA Game Studio 4.0 is offered free of charge.
There are some rumors that XNA is essentially a dying technology. According to an anonymous blogger,
So if DirectX 9 doesn't work with Metro UI, then by extension neither does XNA. And let's face it, Microsoft was never going to spend time and effort supporting DirectX 9 with Metro UI just for XNA games. It would mean including a DX9 runtime in the ARM version exclusively for XNA games, and probably a million other headaches I've not even thought of.
However he goes on to argue,
Most likely the Xbox vNext will run on DX11 or some form of it. If Microsoft plans to put XNA on Xbox vNext (as I hope they do if they're serious about it), then it would make sense to do a full DX11 rewrite of XNA at that point. They can't do it now, because I doubt the software stack for the new Xbox is anywhere near being nailed down yet.
So in conclusion, I believe the lack of Metro support for XNA means one of two things. Either our worries are justified, and Microsoft plans to cut XNA loose OR Microsoft is actually really serious about XNA as a future technology, and is waiting until it can be rewritten for the Xbox vNext and Windows 8 at the same time.
XNA/Silverlight for Windows Phone 7
XNA for Windows Phone and Silverlight for Windows Phone are subsets of their respective namesakes. They contain most of the functionality found in XNA and in Silverlight for browsers as well as some additional libraries for accessing the phone’s hardware.
When Windows Phone 7 was released developers had to choose between XNA and Silverlight. While the technology certainly supported using both inside the same application, Microsoft’s application publishing rules prohibited distributing applications mixing the two UI technologies. This restriction was lifted for Windows Phone 7.5 (also known as 7.1 or Mango).
Generally speaking, XNA is used for games and other applications needing high performance graphics while Silverlight is used for most other purposes.
Mono for iPhone, iPad, and Android
Known as MonoTouch and Mono for Android, these commercial variants of Mono are targeted for iOS and Android respectively. MonoTouch is an incredibly popular runtime and Apple has featured applications that use it in their commercials. Xamarin has recently started showcasing applications using MonoTouch and Mono for Android.
Development with MonoTouch requires the iPhone SDK and membership in the Apple's iPhone Developer Program. Mono for Android requires the Java SDK and Android SDK.
Attachmate gained ownership of Mono, MonoTouch, and Mono for Android when they bought Novell, which in turn bought Mono from Ximian. When Attachmate decided to drop support for these platforms a new company called Xamarin was created to continue the work. While the details of the contract are unknown, Xamarin has essentially assumed responsibility for all past and future development and support.
While all other platforms we discussed so far are essentially free, MonoTouch and Mono for Android each cost 399 USD, putting it out of reach for most hobbyists.
Portable Library
The Portable Library is a cross-platform profile representing a true subset of .NET, Silverlight, Silverlight for Windows Phone, and XNA. Developers can choose which of the four they wish to target and fully supported APIs will be offered to them. This profile is best used for business objects and utility libraries that one doesn’t want to recompile for each platform.
When asked about support for the Mono runtimes, David Kean of Microsoft wrote,
Plans with Mono changed a little when Novell was acquired earlier this year. We're still talking around this, however, I don't know of any firm dates around when this would be fully supported.
The Mono 2.12 release notes mention support for Portable Class Libraries, but no details were given.
.NET Micro Framework
The .NET Micro Framework was designed to run .NET on very small embedded devices. These do not necessarily have an operating system and can run .NET directly on top of a thin hardware abstraction layer.
Originally a commercial venture, the .NET Micro Framework is now being offered under an open source license.
Microsoft Robotics
As the name implies, Microsoft Robotics is a variant of .NET specifically designed for building robotics. Microsoft Robotics is best known to mainstream .NET developers for introducing the Concurrency and Coordination Runtime (CCR) and Decentralized Software Services (DSS). While they are slowly being replaced by features in the Task Parallel Library, these are still the most advanced libraries for highly concurrent, fault tolerant applications written with .NET.
While based on the .NET Framework, programming against DSS is very different than normal .NET programming. Much like the shift from console to GUI applications or from client to web, one has to learn new architectural patterns.
In addition to learning CCR and DSS, developers should learn how to use Visual Programming Language or VPL. This is a high level, graphical programming language expressed mostly in the form of dataflow style flowcharts.
.NET for Windows 8
This is the official name for the version of .NET used exclusively to build Metro-style applications using the WinRT API. It most closely resembles the Silverlight runtime with an emphasis on asynchronous calls for file/network access and a XAML-based user interface that doesn’t support multiple windows.
While Microsoft is calling this a “profile”, it isn’t a subset of either the .NET Framework or Silverlight. Microsoft used this opportunity to remove many deprecated features from the .NET Framework and restructure much of what remained. Even when the class and member names remained the same they are often moved into different assemblies and namespaces. These changes can affect even pure business objects such as those that need to expose INotifyPropertyChanged.
As it is deeply tied to the WinRT APU, .NET for Windows 8 is only available on the Windows 8 operating system. It can be used for:
- Metro-style applications
- WinRT Components for Metro-style applications written in JavaScript
- WinRT Components and User Controls for Metro-style applications written in C++
Due to the namespace changes for interfaces such as the aforementioned INotifyPropertyChanged, it is doubtful that this profile will be supported by the Portable Library profile without significant changes to the runtime.
.NET for Windows Server 8
Starting with Windows Server 8 a graphical user interface will not be installed by default. Since developers will surely want to run applications built with ASP.NET on these servers we may need a version of .NET that doesn’t include any GUI libraries. This profile does not exist yet, but we expect to see it at some point in the near future.
About the Author
Jonathan Allen has been writing news report for InfoQ since 2006 and is currently the lead editor for the .NET queue. If you are interested in writing news or educational articles for InfoQ please contact him at jonathan@infoq.com.
