Hacker News Reader

Comment by Someone1234 | Hacker News Reader

It will be interesting to see how this will work in practice.

C# will port over just fine. But the .Net libraries? System.Windows has little to nothing in it, and right now using things like System.IO.* on Linux and Mac is just asking for trouble.

What are they going to do, hack in System.IO.* Linux support after the fact? Or just add Linux.IO.* which is even more of a hack. In either case you're going to get very messy very fast.

The .Net libraries absolutely could have been designed with cross platform in mind, for example if they put the IO libraries in System.Windows.* and several of the other Windows-specific APIs.

As it stands the .Net framework/libraries are very Windows locked. So much so you'd almost have to scrap them and start over to make it more platform agnostic.

View on HN

"What are they going to do, hack in System.IO"

System.IO works very well on Linux/Mac right now. It was one of the first things implemented by the Mono team.

Having ported numerous .NET applications, all of which do fair heavily file I/O (the most common use case for System.IO), the main sticking point has been code that deals with filenames and paths. As in "/home/billy" vs "c:\Users\Billy". A hour or so of cleaning up your code and making use of Path.DirectorySeparatorChar and IsRooted is all I've needed to do.

"As it stands the .Net framework/libraries are very Windows locked"

This shows a lack of understanding of the .Net framework. Yes, if you used crazy Microsoft specific WCF libraries for networking protocols instead of industry standard stuff, or used WPF for graphics, that going to be a problem. But there are literally thousands of classes providing a fairly comprehensive set of data structures, network protocols, etc that are completely untied to Windows or Microsoft. If you are using something in System.whatever you are pretty OK.

P.s., Sockets aren't in System.IO, they are in System.Net

Deleted comment

I wouldn't call that an insult, much less a passive-aggressive one. Maybe it's time to get a bit of fresh air; the world's not out to get you.

...or maybe it is...just not billyhoffman.

Mono has been doing just fine. Yes, you can't rely on WinForms, even though a port exists. You can't do COM, that's for sure. But that doesn't mean that Mono is not valuable for what it is right now.

Microsoft doesn't need to provide compatibility for the Windows specific bits, as those bits are not part of the Core. And a platform like .NET has enough value in open-sourcing just the Core (i.e. whatever goes in the ECMA standard). For example it's a perfectly acceptable strategy to use GTK# on Linux, WinForms on Windows, MonoMac on OS X and Xamarin.Whatever on iOS / Android.

On System.IO, indeed there are differences between Winsock and Linux's epoll or BSD's kqueue (i.e. notify on completion versus notify on ready). There are differences between the 2 models, but I don't see that as a problem for System.IO and if you think it is a problem I'd like to read an explanation as to why.

Personally I'm very excited about this announcement. I avoided .NET for years and preferred to settle for the JVM because I do not like building on top of proprietary things. If they are really open-sourcing the .NET runtime, whilst uniting their efforts with Xamarin, that's really good news. Now hopefully the ecosystem around .NET will follow, as .NET needs an open-source oriented ecosystem and needs one badly.

Microsoft's focus on this release is the server.

Mono plans on contributing to the effort our cross platform changes to Mono, to make .NET work great on Unix.

Details here: http://tirania.org/blog/archive/2014/Nov-12.html

After reading most comments here, the linked announcement, your blog post & some other websites, I only have one question left. If Microsoft releases their code under the MIT license, will mono follow suit and stop using the GPL?

From Hanselman's post:

"ASP.NET 5 will include a web server for Mac and Linux called kestrel built on libuv."

I've been playing around with kestrel/asp.net vNext (Which I guess is now 5) on Mac, and while it's still rough, it's a good dev server.

I don't think they are open sourcing the client libraries like WPF and Win Forms. Like you are alluding to, what good would it do if they did since it is 99% Windows only functions in there.

They are open-sourcing the server side code. I think this means your ASP.Net apps can run on Windows, Linux, Mac OSX all from the same open source code base. No worry about Mono incompatibilities and bugs.

> I don't think they are open sourcing the client libraries like WPF and Win Forms.

I didn't allude to that.

To be fair thats pretty much exactly what xamarin have done for ios, android and mac.

Yep, and check out System.Console for some horrors in the mono runtime.

System.Console isn't something that most apps rely on. It's handy for printing something out in a tiny one-file test app, but generally not relied upon for bigger apps.

Are servers / daemons not a common usecase? Most, if not all, of the apps I write on a daily basis do not have GUI.

Is this on a UNIX? If so, yes, it's common to write to stdout/stderr there. Not in Windows, though - anything which is long-running tends to be a Windows Service and there's no point writing to System.Console from there because no-one will see it!

I haven't done much .NET on UNIX but if I was doing so, I'd probably want something a bit more UNIX-friendly than System.Console, though I know it does have the ability to deal with different streams.

Are you saying core .NET libraries are worthless?

Because in that case what's the point? Why not just use Java.

I'm sorry, but I have literally no idea how this post follows from the one you replied to?

> I'm sorry, but I have literally no idea how this post follows from the one you replied to?

Literally? Well it is visually displayed under it and to the right :P

Damn, I liked my joke...

Links to some examples?

Ofcourse someone will have to write the linux/osx implementations, but I don't see much in System.IO that would be asking for trouble.

The CreationTime on DirectoryInfo would have to be faked, and it's not entierly clear if FileSecurity would map cleanly to posix acls, but nothing sticks out as being fundamentally incompatible with linux at least.

As far as I understood, they are really slimming down the core .NET CLR (runtime). Most of current BCL .NET libraries will be exposed as separate nuget packages, which makes it really convenient.

Somehow reminds me of the Microsoft/Novell agreement, will wait to see how it turns out...

Reply on news.ycombinator.com