Hacker News new | past | comments | ask | show | jobs | submit login
Open Source .NET – 2 years later (mattwarren.org)
158 points by nreece on Nov 24, 2016 | hide | past | favorite | 46 comments



The community has begun contributing to microsoft-sactioned projects (notice those projects listed are all ms initiatives). There is still weakness in community initiaited/run projects, 2 years later http://www.aaronstannard.com/the-profound-weakness-of-the-ne...


In the blog post that's an breakdown of ms project, yes. Used to show how ms is doing with open source? yes. because .net framework (and implementation of runtime,compiler/blc) was owned by ms (mono is another implementation of the runtime/compiler/bcl).

But for some components is ok to contribute there:

- mono(xamarin) was already migrating to use open source components like the bcl (corefx) after the initial open source of code by ms. It's like dont write two times the same stuff.

- coreclr: the .net core runtime

- corefx: the standard library (base class library like io etc), used by .net fw (win) and .net core and partially by mono

- roslyn: that's the c#/vb compiler, also mono is trying to reuse that

- cli: it's the sdk for building projects. Can the project system changed? yes, but not needed now (.net core it's boostrapping another xplat runtime so need tools). as a personal note, the cli team doesn an awesome job to make it easy to contribute

and some notes:

- asp.net is a web framework, it's used a lot, nice ppl contribute. who like servicestack/nancy/suave, use that instead.

- fsharp (http://fsharp.org/) was and is already driven by community, and lang decision are in repo https://github.com/fsharp/fslang-design by community and lead by @dsyme

And you should also check dotnet foundation pulse and community projects (like Nancy/Nunit/Akka.net/mbrace).

Lots of the work done by ms can be useful for others, see Kestrel server (damn fast) who can be used by other web projects like Suave (https://github.com/SuaveIO/suave is a lib, not a framework :D)

- dnx was the predecessor of cli, and replaced by it (good job by aspnet team to boostrap xplat on netcore)


a lot of this post is around akka. I mean akka is also relativly new... It was released in 2006 so .NET still is in his early stage for such things. I mean Java actually only has akka because of scala. NIO in java is still bad and hard, netty makes that somewhat easier and also the big maintainer of Akka is not Oracle it's actually Lightbend. For me the post makes no sense since Scala didn't had much code out there at the beginnings as well, I took some years to have a various amount of useful projects. (more than two years...)


Not sure what the comment about NIO in Java was for, there are surely rough parts to it even in NIO2, however compared to the status quo, Java's NIO is like a breath of fresh air. Simply because it is hard to abstract over poll, select, epoll, kqueue, AIO, Windows' async sockets, etc and provide consistent behavior over all those supported platforms. Because of this the async I/O implementation in Mono has been broken for years ;-)

As for Akka, well Akka is really not about abstracting over I/O or a replacement for Netty, even though projects like akka-http exist. At this point Netty is so good, well tested and so widely deployed that nobody sane would even dream of replacing it, even though there are some people trying.

And on the .NET ecosystem, I really love what Microsoft is doing with it and how .NET Core is turning out, however open-source is definitely a big weakness of the ecosystem. In the Java world, Oracle is not driving anything other than Java the language and the runtime (i.e. the core). Not the IDE, not the frameworks or the tools being used. Everything else is provided by the community.

And when I click to view the source of some class or method in my IDE, I have my IDE automatically download the original source, instead of getting a decompiled one, because proprietary libraries are almost unheard of.


The future of .NET is on Linux, not windows. If the community and Microsoft both do everything they can to make that a reality, it could all pay off. As long as you see visual studio only tutorials, windows only build scripts and windows only deployment stories, it won't happen.


The future of .NET is on both Windows and Linux. Millions of existing .NET developers are happy to continue making .NET code for billions of Windows devices. On PaaS, it still makes a lot of sense to use Windows as the underlying OS. And, yes, the proportion of Linux vs. Windows underneath will go up, because that's the only direction available.


>On PaaS, it still makes a lot of sense to use Windows as the underlying OS

Why is this the case? I would have thought PaaS of all things would be OS agnostic as the end user doesn't really care about the OS or how things are being done in the background as long as it's simple to deploy/configure etc.

For example if Azure Websites suddenly made this big shift to Linux for some reason, it wouldn't affect anyone actually using the service.


Maybe they meant the future of .NET server side. I could see that in the future with the last holdouts being big corporate server environments already heavily invested in Windows (particularly internal apps).


The majority of desktop applications that we create, and we do create quite a few of them, are mostly WPF, with some new ones now being prototyped in UWP.

So no, .NET on GNU/Linux won't make those customers magically migrate to it, specially since GUI tooling isn't part of .NET Standard.

Even if WPF, UWP and Blend get ported, I don't see those customers changing their IT infrastructure for desktop, device readers and robot controllers OSes.


What kind of WPF applications are you writing?

I'm just curious because I always liked WPF but I don't hear about too many people developing for it these days.


Data manipulation applications for life sciences data analysis, front ends to industrial robot automation systems, control software for medical devices, scheduling systems, ...

Sometimes there is still an inhouse C++ layer for driving the hardware when talking to older devices, but newer ones are covered by standard Windows APIs or OEM provided libraries, so we can write everything in .NET.

If you search for WPF jobs in Europe you will find many people do use it, even for greenfield projects.


How does Microsoft make money on this? Sun spent all this money supporting java, but they ultimately couldn't survive.


I think that if Microsoft makes .NET attractive to a large number of developers regardless of their preferred OS they have a headstart and constant edge on the competition in terms of services that mesh well with .NET. This increases the appeal of Azure and its services. It might be a good shortcut since they're competing with established players who have the early edge. Stealing away a lot of customers from the competition in the cloud space is going to take more than competitive pricing since you're fighting familiarity/experience, first-to-market advantages and a lack of 1:1 features on some services.


The more people they bring I to the .net community the more opportunities they have to sell tons of azure services. Doesn't hurt them to be more open because existing .net shops are still going to pay for msdn, etc.


The same way Office on Mac OS/iOS brings MS Money... services. Office365, Azure, etc.


They use .NET and build their tools and services using it. .NET gets better so does their associated services built using it.


there is not much windows only, check github status of dotnet/cli (the sdk), https://github.com/dotnet/cli#build-status, lots of os supported, just clone + build


As a linux user, I tried:

1) Visual studio only works on windows 2) It runs on mono 3) I don't like .exe and .dll stuff


Jetbrains Rider is coming soon. It's pretty great!


JetBrains Rider Public EAP is out. I've been using the private EAP on Linux for 6 months and it just keeps getting better.

I contribute to a couple open source .NET projects working with developers that use Visual Studio on Windows and don't run into many cross platform issues. I commonly see open source .NET Core projects run Windows CI with Appveyor and Linux CI with Travis so catching cross platform build issues is not hard.


Jetbrains' stuff only works properly on Oracle's proprietary JDK, and not on the reference JDK (OpenJDK), which kinda sucks, doubly so since the former is not re-distributable, making it even more alien in the linux world.


I don't think this is true anymore [1]. They're bundling IntelliJ with custom OpenJDK (with needed bug fixes) in recent releases.

In addition, I run on Azul Zulu [2][3] for Java / Scala / Kotlin development and haven't had any problems so far (switched about a year ago).

Notes:

[1] - https://intellij-support.jetbrains.com/hc/en-us/articles/206...

[2] - https://www.azul.com/products/zulu/

[3] - macOS Sierra at work, and Ubuntu 14.04 at home


I'll completely pass on software that requires (and bundles!) it's own JDK. I already have the reference implementation installed, honestly programs should use that, not bundle their own.

Anyway, I still gave it a try to see how it works. Looks like they're resolved lots of the visual glitches (especially the most serious ones, like font rendering).

For some reason though, after running the app, I was left with two directories in my home with dumps of configs/cache all mixed up. :/


I run it on OpenJDK just fine.


1. VSCode runs on linux 2. On .Net Core 3. meh


VSCode is NOT VS, dude.


Precisely, you get it!


This is quite true.

Using clasic *nix tools (vim+plugins, zsh, etc) plus their CLI tools, I can download and build many C# projects.

Creating a new solution/project? I need an IDE for that. Or copy-paste the base project files from an existing one.


you can just run the dotnet new command.


Has it really been 2 years already? I'm still waiting for a decent build system for .NET projects for Linux or macOS. Last time I tried (~6 months ago), it was a tire fire.


It's even more tire fire now: they're announced 'project.json' build system, but deprecated it[1] in favor of older msbuild. But it's still mentioned on front page of .NET core[2] and used as the primary build system in latest version (I don't know if .NET core even has msbuild, tried only mono).

Almost everyone think that you need some specific IDE (either Visual Studio or Monodevelop/Xamarin Studio/VS for mac (this is the same thing lol)), even in opensource communities[3].

And MSDN is the slowest and hardest to use web documentation I ever seen. Everything non-Windows non-VS is still very, very second-class.

[1] https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t...

[2] https://www.microsoft.com/net/core

[3] http://community.monogame.net/t/creating-a-new-monogame-proy...


ms is maintaining project.json based sdk too with version preview2, so devs can continue to work, no need to switch to new msbuild soon (wait until is done).

ide are good (intellsiense/debugging), especially vscode, but sdk works already from command line and text editor.

about docs, check the new docs website (oss, accept pr):

- https://docs.microsoft.com/en-us/dotnet/articles/core/

- the getting started doc https://docs.microsoft.com/en-us/dotnet/articles/core/gettin... has tutorial for everyone (cli/vs/vscode/xam), and all os. is not vs centric


> And MSDN is the slowest and hardest to use web documentation I ever seen

It is also one of the best company provided documentation out there.

Have you ever used online documentation from Apple, Google, Borland, SAP, Oracle, ...?


Either FAKE (F# Make) or CAKE (C# Make) work perfectly on NIX/BSD systems. The new build system FOR .NET Core works great too with `dotnet build`.


Yes, Cake is wonderful, however, I had great problems bringing it to work due to a lot of issues with NuGet v3 (UTC positive offset bug, looking for msbuild.exe to restore packages, ...). Luckily, I could switch to NuGet v2.

Bottom line is: CAKE is great, but if the project depends on things that are not covered by dotnet core one is still screwed.


> The new build system FOR .NET Core works great too with `dotnet build`

They've deprecated it: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t...


`dotnet build` still works, they've just changed the underlying implementation from the 'project.json' based one to instead use MBBuild


just `dotnet migrate` if you have an old project.json, or create a new one with `dotnet new`.

after that as usual

- dotnet restore

- dotnet build

- dotnet run

- dotnet pack

- dotnet publish

- dotnet test

the cli is the same, the dotnet/cli team added other commands too (dotnet msbuild, dotnet clean, and more in development using an extensibility to install global commands)


> the dotnet/cli team added other commands too (dotnet msbuild, dotnet clean, and more in development using an extensibility to install global commands)

Yeah the cmd extensibility story it pretty nice, I had a go at writing a 'dotnet benchmark' cmd and it was pretty straight-forward, see http://mattwarren.org/2016/10/03/Adding-a-verb-to-the-dotnet...



I might be off topic, but JetBrains is making a cross-platform .NET IDE which is currently in open beta. I tested it and it had no difficulties to open/build/execute existing solutions.


Make?


Is anybody using this new .NET stuff on Linux for production daemons? My experience in using Mono/XSP for backend services wasn't joyful. Willing to try .NET Core (?) on small projects if it is approaching JVM stability.


I have a service running in production for more than a year. No significant issues so far.


My team has been running .NET core for the last few months and it's been great.

Most of us develop on Windows, however I have chosen to use Project Rider as my daily IDE because I run macOS. The latest public build is actually pretty stable compared to the earlier builds.

We're building backend services in ASP.NET Core which is very easy to get started with and quite well thought out. Autofac works too. You'll find most (imho) popular libraries are either fully supported or have a beta NuGet that supports .NET Core now.

Honestly the thread below about Linux being the future is true for server-side .NET. I'm able to develop on macOS, dockerize my service, build on Jenkins with Linux agents and then deploy to Linux docker hosts. I'm not sure where Windows will fit in this space? And why would I need it?


I'd be interested to hear from anyone who has experience with both .net and Swift communities about the differences and similarities in how the projects are run.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: