Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building and Running .NET’s CoreCLR on OS X

praeclarum.org

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Building and Running .NET’s CoreCLR on OS X

#21

Post by Alphasite_ »

henderson101 wrote: post #8
josteink wrote: post #4

Earlier quoted context omitted.

> without crazy licensing fees as with Mono Are you confusing Mono for Xamarin?

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…

Also, afaik iOS now supports dynamically linked frameworks.

Re: Building and Running .NET’s CoreCLR on OS X

#22

Post by carussell »

tiernano wrote: post #6
josteink wrote: post #4

Earlier quoted context omitted.

> without crazy licensing fees as with Mono Are you confusing Mono for Xamarin?

Mono is the framework (like .Net) and Xamarin is the tooling (like Visual Studio). Framework is free (essentially) and the tooling is like VS (starter is free, pro is not so free but has more tools)

Xamarin Studio is just a rebranded MonoDevelop with a few proprietary Xamarin supplements.

Re: Building and Running .NET’s CoreCLR on OS X

#23

Post by Romoku »

albertzeyer wrote: post #15

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,…

Take a look at XWT[1]. It uses the native rendering on each platform.

[1]: https://github.com/mono/xwt

Re: Building and Running .NET’s CoreCLR on OS X

#25

Post by freeman478 »

gleenn wrote: post #11
chii wrote: post #9

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.

Scala did but I think they abandoned it.

Clojure is also available on the CLR : http://clojure.org/clojureclr

Re: Building and Running .NET’s CoreCLR on OS X

#26

Post by henderson101 »

Alphasite_ wrote: post #21
henderson101 wrote: post #8

Earlier quoted context omitted.

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…

Also, afaik iOS now supports dynamically linked frameworks.

No idea - it always has - but the loader specifically disallowed it except for "special" Apple frameworks.

Re: Building and Running .NET’s CoreCLR on OS X

#27

Post by henderson101 »

floatboth wrote: post #17
henderson101 wrote: post #8

Earlier quoted context omitted.

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…

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

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.

Re: Building and Running .NET’s CoreCLR on OS X

#28

Post by jbigelow76 »

adolfojp wrote: post #18
albertzeyer wrote: post #15

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,…

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. The purpose of this is to avoid the uncanny valley of cross platform toolkits like Java Swing at the expense of writing extra UI code. Some wrappers like Eto.Forms and XWT exist but don't expect drag and drop visual designer tooling. Thanks to Mono WinForms is sort o…

    >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.
What are the odds Microsoft announces WPF open sourcing and maybe a wrapper of some sorts for OSX support at Build this year? I give it at least 50/50 on the open sourcing part.

Re: Building and Running .NET’s CoreCLR on OS X

#29

Post by stinos »

tonyedgecombe wrote: post #24

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

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.

Re: Building and Running .NET’s CoreCLR on OS X

#30

Post by c0wb0yc0d3r »

jbigelow76 wrote: post #28
adolfojp wrote: post #18

Earlier quoted context omitted.

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. The purpose of this is to avoid the uncanny valley of cross platform toolkits like Java Swing at the expense of writing extra UI code. Some wrappers like Eto.Forms and XWT exist but don't expect drag and drop visual designer tooling. Thanks to Mono WinForms is sort o…

>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. What are the odds Microsoft announces WPF open sourcing and maybe a wrapper of some sorts for OSX support at Build this year? I give it at least 50/50 on the open sourcing part.

If they did that I would be so happy! I think if they did that it would set the CLR up to effectively compete with Java.
Post reply on HN