Building and Running .NET’s CoreCLR on OS X
praeclarum.org
praeclarum.org
If it's anything like MSCORDACWKS (which "mscordac" alludes to), it's an absolutely crucial piece of code. Basically it's an abstraction layer over the way .Net lays things out in memory. It's aware of the .Net heap structure, threads, stacks, object headers, you name it: it knows how to abstract it and read it.
This means that if there is a production issue at a customer, you can grab a memory dump from them and this one tiny DLL - and then you can start digging into things (Microsoft actually now provides differing versions on their public symbol servers: so you only need the memory dump nowadays). I'm pretty sure it's also how Visual Studio interacts with .Net memory.
Unlike other environments where you have to have the same version as the customer, or at least a compatible one.
Microsoft ships it with the .Net installation package and you [Mac users] should always keep it next to coreclr, too. Literally, deploy it with alongside coreclr and mscordac. Never let them be apart, ever. Don't just ignore it, having the correct version will save your bacon one day. 4KB that will wrangle gigabytes of dumped memory for you.
Thank you for the clarification!
Can I write cross-platform GUI code, or would I need to re-implement the GUI on every platform?
Do Windows .Net GUI apps (does that mean Windows.Forms?) work just as-is on Linux (and maybe MacOSX)?
What would be the best supported GUI .Net framework? QtSharp? Windows.Forms?
I found some overview here, but not sure if accurate / up-to-date: http://www.mono-project.com/docs/gui/
Text components in particular are very broken. Text selection, context menu, copy and paste, cursor movement, rendering, it's all very shaky.
Use Gtk# on Linux.
Especially on Mac it does its own control rendering and, while it tries to match the OS, has problems.
XWT was meant to replace GTK# and has some good underpinnings but it doesn't seem super active right now.
Some wrappers like Eto.Forms and XWT exist but don't expect drag and drop visual designer tooling.
Thanks to Mono WinForms is sort of cross platform to a certain extent but if you give it a try you'll see why it is not recommended.
>Cross platform .NET usually means using a native toolkit on each different platform and the result is WPF on Windows, GTK# on Linux, and MonoMac on Mac.
As someone who worked on WPF though, I will comment that the code may not actually be too useful. It is heavily tied to Windows and its graphics infrastructure.
I'm more interested in seeing something like Moonlight ported to modern platforms.
Open Sourcing it is one thing, converting that into an engine that can do layout and rendering identically across multiple platforms is non-trivially difficult. Talk to the browser folks on how hard they had to work on that, and they wern't dealing with 3D stuff.
It's pretty solid and easy to use and I'm quite happy with it. If you want an exquisite, beautifully-designed OS X app then you should be looking into having separate frontends per platform anyway, but having tried Eto I find it fits my needs.
It's much better than I expected.
These days I lean towards web services and using the browser as the GUI.
For cross-platform desktop applications, I've been keeping an eye on Perspex: https://github.com/grokys/Perspex
Are you confusing Mono for Xamarin?
Yes, iOS was a lot of work. Yes, if they want to make it a commercial venture, that is their right, but Miguel has gone on record stating that no one else can do this due to the way the Mono runtime is licensed. They refused to give a static linking exception, as some other libraries do, so basically your only option is their solution or your own written from scratch. This is why the CoreCLR is cool.
Also - did you notice Mac is in there too? If you build a self contained package using Mono (embed the runtime in the App Bundle) they want you to pay for that now. Even though this has about zero to do with static linking.... I had a 10 minute long argument with a Xamerin representative about how retarded this was, as people have been embedding the Mono Runtime in their Mac apps for quite a long time now. But no, apparently we now pay for that.
I was on the Monotouch Beta and it looked so good. It's a pity the initial pricing was so absurd and even all these years later, it is still impossible to build an app for iOS with the Mono framework without a fee on top of the Apple Developer license. This is why I stuck with Objective-C.
Microsoft's CoreCLR is MIT licensed. Nice. :-)
I guess what I'm asking is, where's the open-source MSVS C# compiler core+build system+CLI tooling?
Ouch. They should really look into using clang and its integrated assembler. All mnemonics should Just Work. as on mac is a patched up binutils 1.38 version.
Near as I can tell there is no support for the short operator either. Am I missing something?
As a pragmatic issue, if you weren't already using Mono, then it would probably be wise to let the newly open-sourced CoreCLR stew for a while to find subtle kinks introduced by the process through which it was open-sourced and/or the pressures exerted upon it by full-time dev or test (or even prod!) usage on non-Windows platforms.
As a much more subjective issue, Intellij versus every C# editor is an unfair matchup. It's possible JetBrains will get into the C# editor space now that they might have more marketshare who are not on Windows, but it's probably very far down their priority queue.
Cocoa's AppKit is very powerful and provides a UI that has always been more consistent than what I've experienced on Windows. The last time I tried .Net/WinForms several years ago it was severely lacking in the functionality and flexibility of controls like tables and toolbars, and the UI of many Windows apps still tends to look and act slightly different from each other, with Microsoft being the biggest culprits in this inconsistency.
So it's not going to suddenly open the floodgates of .NET apps running on a Mac. That's still a long long way away (if at all).