
Building and Running .NET’s CoreCLR on OS X - xvirk
http://praeclarum.org/post/110552954728/building-and-running-nets-coreclr-on-os-x
======
zamalek
> libmscordaccore is that. I’ve heard that it “helps debugging”, but at 4KB, I
> have my doubts. No, this is just an ugly wart growing off an otherwise
> prefectly packaged piece of software. Best ignore it.

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.

~~~
praeclarum
Sorry - I have a very client-side/consumer facing attitude and these low level
debuggers just don't matter. But I acknowledge that it's certainly useful in
the scenario you outlined.

Thank you for the clarification!

------
albertzeyer
Now as .Net becomes more interesting again (for me), can someone comment on
the state of GUI app development in .Net?

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/](http://www.mono-project.com/docs/gui/)

~~~
floatboth
WinForms works on Mono (but looks like ass). WPF doesn't. The best way is
probably Gtk#.

~~~
praeclarum
In terms of maturity and feature-completeness, GTK# is the answer.
Unfortunately, it's no beauty either.

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.

------
asp_net
I really like how things are going forward. Being a .NET developer since 2004
and a Mac user since 2008 I can't wait to use my beloved tooling finally in
production on Linux (and on OS X for development).

------
ianlevesque
I realize there is much yet to do (hand assembled bytes?!) but it's impressive
to see this building and running already.

------
henderson101
If this can be used to open up more platforms, without crazy licensing fees as
with Mono and mobile devices, I think it is a very positive step forward.

~~~
josteink
> without crazy licensing fees as with Mono

Are you confusing Mono for Xamarin?

~~~
henderson101
No - Mono has crazy licensing restrictions and massive licensing costs for
statically linking their framework. Xamarin offer a better option, but there
is no "free" alternative using C#, nor could you create one with the Mono
framework. The CoreCLR does have the possibility to get around this as the
code required for creating a solution is not licensed in the same way.
Xamarin's entire business model revolves around the fact that static linking
is not allowed using the Mono Framework as a basis.

~~~
floatboth
I think their business model revolves more around selling their proprietary
bridges from Mono to mobile platforms' native APIs (MonoTouch and MonoDroid,
now marketed as Xamarin.iOS and Xamarin.Android).

~~~
henderson101
No, that's not really true. Their business model revolves around licensing the
mono runtime to end users (in this case Developers) along with some extra
platform specific code. In the case of iOS that is a statically linked exe
build from AOT compilation of the CLR code. For Android that is a runtime that
sits on the device and is shared for each exe, and for Mac that is taking the
Mono Runtime and moving it in to the App package.

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.

------
derefr
I was expecting a "complete bootstrap", but even after the end of this article
you're still using Mono to compile any further executables you want to run on
CoreCLR, right?

I guess what I'm asking is, where's the open-source MSVS C# compiler
core+build system+CLI tooling?

------
jevinskie
> Rewriting bits of high performance assembly in bytes (not opcodes) as Mac’s
> as refused to generate the desired instructions.

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.

~~~
kangaroo
We are using clangs integrated assembler. The issue is its always choosing to
emit jumps in long form which is screwing the aligned of the imm's which are
patched at runtime.

Near as I can tell there is no support for the short operator either. Am I
missing something?

------
chii
i wonder if other languages can start targeting the CLR, and have a competing
cross platform runtime to java that's got a big name behind it.

~~~
ubertaco
As a POSIX-loving, open-source-breathing guy: platform availability being
equal, why choose Java over C#?

~~~
mdaniel
I would venture it's a ton easier to find Java programmers than C# ones (at
the current moment), and the same story for libraries for likely the same
underlying reason.

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.

~~~
axefrog
Visual Studio + ReSharper. Hardly unfair.

------
Razengan
I just hope this doesn't reduce the overall quality of upcoming Mac apps.

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.

~~~
wluu
I think the focus of the CLR/.NET team at MS at this stage is on the server
side (eg: ASP.NET).

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).

------
tonyedgecombe
I'll be impressed when WPF is ported to OS X.

~~~
stinos
Aren't you at least a _bit_ impressed now? Some proprietary software giant
releases a bunch of source for a pretty nice piece of software and it builds
and works on another proprietary giant's system. Not only the fact it works,
but also the amounts of work gotten into making it work i.e. getting all
platform specifics out of the way, and also the premises for the future it
seems to hold (especially since it also works on yet another but non-
proprietary giant's system) did impress me.

