Submitted by This is the first Mono release that contains code from Microsoft’s open sourced .NET code.
We are only getting started with this work. We are swiftly moving ahead in mono/master much more code that is being replaced and ported.This version also is the first one to ship with C# 6.0 enabled by default. Learn all about C# 6.0 in only eight minutes on this presentation.
The release notes will tell you more.
Since MS has open sourced .NET, is Mono on par with it, or just an incomplete version of it?
They are taking some parts of it, while re-focusing more in mobile platforms.
Think of Mono and Core CLR as multiple implementations of the ECMA standard, just like there are multiple implementations of other standardized languages.
It is the other way around actually. Not all of .NET has been Open Sourced. Microsoft’s CoreCLR (which is Open Source but not production released yet) does not include all the Base Class Libraries.
Mono is a much more complete implementation than the CoreCLR will be. Mono is taking a lot of the Microsoft code though and incorporating it into Mono now. It is weird to look at the code for things as fundamental as Integer and Decimal types in Mono and see Microsoft copyright headers.
Mono already included loads of Microsoft code including the DLR, EntityFramework, ASP.NET MVC, MEF, and F#. Roslyn (the next generation C# and VB.NET compilers) runs on Mono as well. So, there are actually two different C# 6.0 implementations running on Mono now (mcs and Roslyn).
As I understand it, Mono plans to mirror the Microsoft architecture with a MonoCore and a full Mono stack. They will look more and more like each other over time I would think.
Edited 2015-05-08 19:11 UTC
Before answering that…
Microsoft has open sourced a new version of .NET, specifically what they are calling .NET Core. Open sourced in the sense that they are developing it “in the open” and they are accepting pulls from the community. It contains most of what was previously consider the core .NET framework, but not all (about 80%).
The existing Microsoft .NET framework is not open sourced under the same terms. The source code is available, but it is developed internally and they do not accept external code.
It is a subtle but important difference. MS is developing .NET Core with the open source community, but they develop and publish the .NET reference framework code for the open source community (to go and do with as they wanted).
Mono is both more complete and less complete than .NET Core, at least if the platform you are targeting is Linux.
It is more complete because at this time .NET Core doesn’t include any GUI stuff at all, but Mono has libraries for doing GUI development. While they are not technically compatible with .NET proper, they work and they exist – there is nothing available directly from Microsoft to do this kind of stuff on Linux yet. Ximian also incorporates their own implementations of some .NET framework libraries that are not part of .NET Core.
It is less complete, however, in the sense that there is some stuff in .NET Core that is not yet available in Mono at all. Other stuff, like WCF and System.Web, Mono intends to replace their incomplete libraries with the libraries from .NET Core.
Honestly it is all rather confusing right now. If you want the answer as it will be in say a year or so, Mono will probably incorporate nearly all of .NET Core, they may even lean more heavily on it and eliminate some redundant parts of their framework (though I doubt it).
Either way they will still have a very good reason to exist – namely to plug some of the holes that .NET Core created and to offer compatibility shims for different GUI libraries on Linux. It is doubtful that Microsoft will ever implement something like WPF for Linux, that is where projects like Mono will step in.
Edited 2015-05-08 19:32 UTC
You’re definitely not wrong about that
Still though, your answer made a little more sense than the others.
Do you know how all of this ties into the Windows ‘universal apps’, or whatever the hell Microsoft is calling them this week? Is that like another framework entirely? I got the impression they were ditching .NET for everything but server stuff.
No idea to be honest… I read and play with this stuff as much as I can because I’m getting old as far as programmers go (trying to make sure I don’t let my skills rust relative to the younglings). Honestly though, I can’t make heads or tails of it all right now as far as universal apps goes. There is a lot of explanation concerning “the vision”, but rather little on how all the moving pieces fit together in reality (which is all I really care about).
If you can make sense of it please explain it to me
So my ignorance made me go digging…
I read about 30 recent articles concerning .NET Core, Universal Apps, WinRT, etc. etc. and this is what I managed to filter out of it all:
1. Universal Apps are WinRT apps, so they will run on desktops (metro UI only) and Windows Phone. Right now you can’t build “classic” desktop apps using WinRT.
2. The UI layer used in universal/WinRT apps is implemented within WinRT itself, which is native code and is exposed through COM (with some enhancements). It has nothing to do with .NET and has no relationship to WPF/Silverlight other than they both use XAML and working with it is very, very similar from a programming point of view. Imo, it essentially looks like they merged WPF and silverlight while moving the implementation outside of .NET.
3. You can build universal/WinRT apps using .NET languages (VB.NET, C#), but you don’t have to. WinRT has “projections” (marketspeak word for bindings) that let you bind with it from different languages. You can, for example, use C++ or JavaScript.
4. WinRT projections (bindings) essentially hide the nasty COM stuff from you… In C#/VB.NET it feels like you are working with .NET libraries, in C++ it feels like you are working with native C++ classes. You don’t have to know COM to work with it, and in fact they don’t really document how to work with it through COM (although apparently some people have figured out ways to do so – but it all seems kinda pointless).
Coming back around to .NET/.NET Core. These really have nothing to do with WinRT or Universal Apps other than being one technology stack (of many) you could choose to do your coding with. WinRT supports .NET, but it isn’t built with it.
One thing to add: Universal Apps use the .NET Core API surface, for the most part.
There is a subtle difference between WinRT projections and COM bindings. There have been roughly 5 technology upgrades in this area: OLE -> COM -> ATL -> .NET/CLR Assemblies -> C++/CLI -> WinRT and C++/CX. I like to think of the phases as follows:
OLE (Object Linking and Embedding): The realization that manually linking C functions (LoadLibrary + GetProcAddress) sucks for anything beyond the trivial case. OLE was invented out of need for Office apps to embed each others documents.
COM (Component Object Model): Standardization of the concept that an object can implement multiple interfaces you can “dynamic cast” (QueryInterface) to. Optimized for (90’s) C and C++ with the usual software architect overkill.
ATL (Active Template Library): Realizing that COM actually sucks both when declaring interfaces and consuming them, Microsoft tries to write a C++ template wrapper library to reduce the pain. It largely fails – now you have two complex things to understand instead of just one.
.NET/CLR Assemblies: Same concept as COM, except this time built around the CLR. It works great for CLR native languages such as C# and VB.Net.
C++/CLI: The attempt at mapping C++ to the CLR. It ends up rather terrible because C++ and the CLR are not really good matches due to subtle details like garbage collection (destructor vs finalizer) and reflection (incompatible type systems basically).
WinRT and C++/CX: This is where they finally fix the key issue, that they must define a common subset that is compatible with both worlds. There is no ‘binding’ required because the individual type systems are compatible. That is why they call it projections rather than bindings.
In a way you can say it is the JSON of the COM world. The magic of JSON is that it defines a data exchange format easily supported in any language as it only really includes stuff everyone has. WinRT attempts to do the same for interfaces.
Sorry for the long rant.
Thanks for that, very informative. It’s still all confusing as hell though. MS seems to be going in about 8 directions at once right now, but at least I think I’m starting to see where all the different paths lead. Fun times ahead
Actually you are right. They are ditching the .Net framework and are only maintaining the Core runtime. Moving forward the framework will be maintained by Ximian. Note that WinRT is not the .Net framework, so it will still be maintained by MS as long as Windows exists. The last official .Net framework release from MS will be v4.6. Then again MS could change their strategy when a new CEO steps in.
How do Microsoft and Ximian do GUI stuff in the future?
That would be:
WinRT for Windows 8.1-10.
WPF for Windows 7.
GTK# for Linux.
Cocoa# for Mac.
If you want cross-platfom GUIs, XWT (analogous to Java-SWT):
https://github.com/mono/xwt
> WinRT for Windows 8.1-10.
Aha. I see. And what’s the difference between WPF and… “WinRT”? In “WinRT” you write GUI in.. XAML, in WPF – in… XAML.
You are mixing stuff.
WPF is a .NET GUI toolkit that uses XAML for defining the GUI layouts. You can code WPF applications just with code, without any XAML.
WinRT is an evolution of COM, geared towards becoming the new Windows ABI for the so called universal apps. It also uses XAML for the layout definitions.
XAML is XML based and has multiple versions. Silverlight, WPF, WinRT all use XAML, but each version doesn’t offer 100% API coverage across all platforms.
There is a new WPF version coming, just in case you missed BUILD.
They hardly need a new CEO for that. Microsoft’s biggest problem has always been that they change their technology stack every 3-5 years. After a little while you get tired of it and just stick to one of their “legacy” solutions until they get their act together.
Yeah, but if you’re just starting out like me, which one of their legacy solutions would you go with?
Lol
The newest of course! Although one of the other big problems Microsoft got is that they always sabotage their own tech as well. So you’d have to pick something that they also support on Windows 7 (unless you want to restrict yourself to 20% of the market).
The newest is not always the one with most future ahead of it. It is possible for corporations to own up to mistakes and then back away from them.
One of my gripes with Java is the outdated runtime and framework cruft that holds it back. When news broke out that Sun is on sale, I dearly hoped that IBM will not screw it up. Unfortunately for everyone (especially folks in Apache) the crown jewels went to Oracle. IBM made a huge blunder by being an utter cheapskate. Oracle has hardly made any significant improvements to the JVM since. This has made new paradigms and tools difficult. I believe languages like Scala and Clojure will continue to have a hard time on the JVM as long as Oracle owns it.
If you want a technology stack that doesn’t change or switch paradigms, then Java is the place to be. After running into severe roadblocks with Scala on the JVM, I am moving to F# on .Net. At least MS makes an attempt to innovate and deliver technologies that evolves with the times.
I don’t think you were paying attention, because IBM ultimately did not want Sun due to potential antitrust issues.
Then why did they even bother to make an offer? Were the lawyers asleep when they made an official offer to Sun? I have not seen any actual facts to support the anti-trust angle.
FYI, Oracle is not as invested in Java as IBM even before the Sun acquisition. They owned BEA, JDeveloper and raft of other Java IP and tools but do not have the scale and depth that IBM has (Eclipse, OSGI, J9, OTI, etc). Oracle had made it clear they had no intention of innovating other Sun platforms/technologies. There are no new SPARC/Solaris innovations, only customers jumping ship. Oracle’s move was to gain control over Java to strong arm industry players and subdue MySQL. All the issues with anti-trust are just hyperbole created by Schwartz and his team to hide the fact they were calling it a day and wanted shareholder support for the highest bidder of their company. The fate of SPARC/Solaris/MySQL would be no different if it were at IBM, at least Java would have made greater progress with contributions from J9 and a raft of better IBM IPs. What innovations have been developed at NetBeans since the Sun acquisition? Stronger integration with Oracle tools?
This is what Ellison originally stated before talks with Sun:
Ellison didn’t always see Sun as a desirable takeover target. In 2003, when Oracle was in the throes of trying to acquire PeopleSoft, Ellison said that buying Sun would be a “bad idea.” At Oracle’s annual shareholder meeting that October, Ellison said: “I don’t think Oracle should be in the hardware business, so I don’t think you’ll see us buying any hardware companies.”
Source:
http://www.cnet.com/news/oracle-to-buy-sun-in-7-4-billion-deal
So what? That doesn’t mean IBM has any responsibility to buy Sun.
I didn’t mean to imply that Microsoft should never try improve their tech. They just tend to have unrealistic expectations of just how much app developers are willing to rewrite per technology upgrade.
Let’s for instance say your company is Autodesk and your product is 3D Studio Max. To support Windows 8’s new Metro UI and WinRT runtime they were asked to:
1) Rewrite all the UI. In a product the size of 3D Studio Max that is literally hundreds of forms.
2) Rewrite the “model” backend (the scene as stored in memory and on disk) as it was based on some old COM IStorageSomething containers and interfaces.
3) Rewrite their plug-in interfaces as they were based on #1 and #2.
4) Tell every 3rd party plug-in developer to rewrite their UI and code interfacing the public model API.
5) Drop Windows 7 support or greatly increase the complexity of their build environment. This is because all of WinRT, even the most basic stuff like the System.String class, is not supported anywhere else.
Strangely enough they decided not to do it!
Now, don’t get me wrong. I consider WinRT to be a very nice technological improvement over COM, as it simplifies and standardizes interfaces in such a way that makes them natively compatible with both C++ and CLR languages. But their all-or-nothing approach to things forces way too many developers to pick nothing.
Honestly, Autodesk is a very poor example. They are nothing but a monopoly after buying out their major competitors. They are holding back the CAD/CAM/VFX market, read up on what they did to XSI as a case in point.
I have more faith in Blender upping the game than 3DS Max would.
You say that about Microsoft…? Man, you should come over to the even darker side and try your hand on Apple’s stuff for while
Granted with Apple such efforts at mass transition are seemingly less frequent, but man when they happen it’s brutal.
Microsoft does try to herd their devs in new directions, but if you don’t follow they still tend to support you for quite a long time. Apple just cuts your legs out from under you when they are ready. It does have the advantage of keeping cruft from building up, but it isn’t fun.
So much disinformation.
.NET is the runtime for managed languages, just like libc is C language runtime, and will be around for a very long time.
The full framework is the way to go for server applications and distributed Azure deployments.
WinRT is the evolution of COM and future Windows ABI that all Windows Universal Apps should target, including .NET based ones.
A .NET application can make use of their own APIs, consume WinRT APIs or expose APIs to be consumed by other languages that are able to speak WinRT.
.NET is not going away any time soon, not even the full stack.
They are just making .NET consumable for those that want to develop web applications in .NET, but deploy in alternative OS in cloud providers.
Anything desktop specific is kept closed for the time being.
Edited 2015-05-09 17:11 UTC
Not according to the mission statement for .Net 5 Core and the latest updates (link below). It seems all the work on the 4.6 framework will be broken into parts and be community driven for future updates. CoreFX, DNX (NuGet next gen), UAP (WinRT, MVVM, .NET Native) and Azure related (ASP.Net, ER, etc) are all that will have an official road map from MS. Unless I hear of a .Net Framework 5 in the pipeline from MS, I think that is pretty much how things are going to be moving forward. My guess is only Ximian will continue to release a full framework, at least that is what their current road map looks like.
Latest .Net info:
http://blogs.msdn.com/b/dotnet/archive/2015/04/29/net-announcements…
Edited 2015-05-09 22:03 UTC
Just because they will be shipping updates via NuGET, it doesn’t mean the whole .NET framework stack isn’t being worked on as a whole, from my point of view.
I also recall there was a BUILD session where it was mentioned that future versions of .NET releases would be a set of stable releases from all available NuGET packages.
Specially important for enterprises with their long update cycles.
I think it is more semantics. Most of the framework seems to be available in the Universal apps world.
Edited 2015-05-10 04:30 UTC
I get the impression when it comes to WPF that they’re gradually going to kill it off in favour of XAML (animation being done using HTML5 technologies) and Silverlight will eventually be replaced with services like Lightbox and Amazon using EME (Encrypted Media Extensions). Maybe this is an opportunity for Microsoft to clean up .NET in the light of what is happening in WinRT and the creation of a AOT compiler which will bring native speeds (or at least near native as possible). Long term if we need to have a managed framework I’d sooner it be .NET when compared to the mess that Java is and the failure for Oracle to ship a version of Java that actually works properly on OS X without having applications continually request specific versions of Java just to get running (I’m looking at you JDownloader).
It’s not open enough for running on Android or iOS and you have to purchase a special license from them.
Thankfully CoreCLR and Microsoft’s investment to compile .net to bytecode using LLVM will make us forget about Mono soon..
Amen.
why shitty? developers also need to earn money from their work.
Shitty because they purposefully put a roadblock in front of static linking to artificially protect their mobile world, then tried to pretend that also applied to embedding the framework in to Mac app bundles.
Hopefully with the code drop, the runtime component that was blocked will be able to be replaced by the actual Microsoft code.