> 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.
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.
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 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.
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.
AFAIK WPF is managed by the Windows team. All this open sourcing has been happening form the Azure and developer teams. Chances of Windows open sourcing some of their code? Less likely.
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.
WPF is very heavily tied into DirectX and other Windows-only APIs.
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.
Windows RT (aka Metro, aka Store Apps). It's a model based on WPF but not fully compliant - it took in lessons learned form Silverlight. Call it WPFlight.
That's the toolkit if you want Metro apps, dealing with MS's crappy store, etc. etc. If you want a traditional Windows application that just works, then WPF is fine. (And I think WPF has an option for non-blurry text rendering, whereas every Metro app seems to be blurry.)
Okay, yeah, so still XAML. I've only recently looked into Windows RT, my time was always spent in ASP.NET, so WPF/WinRT/Silverlight, it all seems like the same thing to me, but I do know a lot of Windows app developers that bitch up a storm about the diffs between WinRT XAML and what can be done in WPF :)
I've been messing with Eto.Forms recently. You define everything through code (or optionally in a JSON blob) rather than in a designer, and it tries to use native controls to display your design.
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.
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).
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.
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.
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.
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)
Mono has a lot of GPL code. Xamarin has a license to impart commercial licenses to their customers. So Xamarin customers are fine. Mono users will have to abide by the GPL'd bits.
Xamarin For Android and iOS only have "crazy" licensing fees IF you want the professional editions... The Starter edition is free, and their Indie edition is $25 per month: https://store.xamarin.com/.
Yeah, the pricing improved - but essentially, it is impossible to create the same exe for iOS using the open sourced Mono version because of the way in which the runtime is licensed (strict LGPL.) No static linking, so one must buy a commercial Mono license, which would not be the case for this solution.
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?
> 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.
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?
What got me interested in the CLR in the first place was how easy it is to write a compiler for it. When insomnia hits, I'll still load F# and write a little parser and code emitter for some silly language I have been thinking of. It's fun.
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.
One of JetBrains primary products is Resharper. It's a must have add on for Visual Studio. If we're going to be subjective I'd say no other IDE gets close to the combination of Visual Studio and Resharper.
Tooling and libraries. If JetBrains cranks out a .NET IDE then sign me up. I don't really want to learn Visual Studio. Also I develop on Linux primarily so VS isn't even an option.
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.
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.
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.