Announcing .NET Core 2.0 Preview 1 | Hacker News Reader

Announcing .NET Core 2.0 Preview 1

blogs.msdn.microsoft.com

67 pointsrunesoerensen23 comments

Interestingly the referenced ASP.NET Core 2.0 announcement[0] addresses the .NET Framework incompatibility issue discussed on HN yesterday[1]:

>This preview version of ASP.NET Core 2.0 ships with support for the .NET Core 2.0 SDK only. Our goal is to ship ASP.NET Core 2.0 on .NET Standard 2.0 so applications can run on .NET Core, Mono and .NET Framework. As the team was working through the last of their issues before Build, it was uncovered that the preview of ASP.NET Core 2.0 utilized API’s that were outside of .NET Standard 2.0, preventing it from running on .NET Framework. Because of this we limited Preview 1 support .NET Core only so it would not break a developer upgrading an ASP.NET Core 1.x application to ASP.NET Core 2 preview on .NET Framework.

[0] https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-...

[1] https://news.ycombinator.com/item?id=14297974

Well that's a reassuring conclusion to the mini PR disaster that was that issue yesterday.

I just read through that as someone who had been semi-following .NET Core up-to the project.json mini-crisis and I am completely lost. How is anyone supposed to just pick up (.NET Core|.NET Standard|.NET Framework) and understand what framework they need to for their app/library to work. I think at one point .NET Standard Apps were even renamed to .NET Core Apps. Are we supposed to open up the Venn diagram until we remember it?

There's a diagram floating around in their site and presentations on Youtube which I don't have access to at the moment. I might be wrong but I think one would pick Core to target multiple platforms, including Windows, and Framework only to target Windows. Standard seems to be the API that libraries should target so that they can be used on all the different supported platforms and devices.

Yeah, Standard is the intersection of the 3 APIs that MS says will work no matter which you target, without needing BCLs. Core is a bit different, but not that different from Framework API-wise, and it will run anywhere, but has no native UI support. Framework is the original blend, and it is probably going to be mostly used for desktop applications and games going forward.

Core is the future, they tore a ton of the old, obsolete features out, but it means that porting a codebase that relies on those is non-trivial. Significantly, it doesn't support Web Forms, which is great for developers but a hard sell for managers.

> without needing BCLs.

Nope, that doesn't even make sense. The BCL is where all the base classes live.

> Significantly, it doesn't support Web Forms, which is great for developers but a hard sell for managers.

I can't tell if you're trolling or are serious, if you are serious that's pretty sad. WebForms is an abomination. Just because you can use drag and drop controls and "magically" get AJAX working in the background does not mean it's a good thing. I don't even know where the "great for developers but a hard sell for managers" comes from. If by your own admission it's so great, why is it not the other way around with developers hating it and managers pushing for it?

Either way, that scenario doesn't happen. WebForms has for literally years been as dead as the dodo, with only 1) legacy applications using it or 2) developers who don't have a clue and haven't bothered trying to learn anything modern.

ASP.NET MVC or ASP.NET Web API with a TS/JS frontend are the only 2 options you have.

So I went to their API docs and for example Microsoft.Win32.Registry is part of ".NET Core 2.0" but not ".NET Standard 2.0". I'm not sure what to make of this. It leds me to believe they have an emulation of the Windows Registry for non-Windows targets using .NET Core 2.0 as there is no warning this lacks non-Windows implementations. After all, .NET Core 2.0 is a physical, cross platform product. But is that really the case? Or will I suddenly run into some e.g. NotSupportedException?

Is there any news about CoreRT? That is what I am excited for, and that would make me consider C# instead of Go.

They're working on it. If their Github milestones are accurate, they're planning a 2.1.0 release in July: https://github.com/dotnet/corert/milestones

I'm a bit curious, what are you planning to use CoreRT for?

I am system developer. So go,python,c# neither are my work language (which is C and some C++).

But i dont do everything in those two (that would be insane). I so everything non critical in python. But dynamic typing is killing me. So i am thinking about other language Go and C# and Scala-Native are bterr than others. But i want full AOT experience. I am done with whatever VM, Interpreter , etc. I want simple executable at output.

About corert last news i saw claimed it is completely in alpha stage. Is this true? For example whole reflection subsystem doesn't work yet. Is this true? (It was sometime ago i saw that news)

Wow, i talked so much.

Personally I like more the idea of C# native or Kotlin Native than Go (too simple) or Scala (too complex).

Regarding CoreRT, I think it's still work in progress. However, you could just use the regular dotnet core for now, you'll just deliver a zip initially. Then as soon as CoreRT is ready (which should happen this year) you can just switch to that and deliver just an executable.

It's really hard to pick something at this stage since except for Go none of the alternatives are production-ready right now: CoreRT, Kotlin Native, Scala Native.

So it's more about which language/ecosystem you prefer and which one you see growing faster/more. CoreRT has Microsoft's backing, so things will definitely happen. Kotlin Native is backed by Jetbrains, so it should also advance. I'm not sure who's backing Scala Native, there must be a company paying the bills for the initial development.

Did you consider OCaml?

Yes, great language, awesome concepts. But not good tooling, and I am obsessed about tooling in user space programming. I spend enough time in C/C++ development inside simple text editor and command line. I want editor support / linting / auto completion / etc.

BTW if CoreRT supports F# as first class citizen. I would jump in it in heartbeat.

It's also being worked on: https://github.com/dotnet/corert/issues/2057

Have you considered to use something like mypy[0] to check your types in python, they added it to python a couple of years ago[1]

[0] http://www.mypy-lang.org/

[1] https://www.python.org/dev/peps/pep-0484/

You can publish a .NET Core application to bundle the necessary "VM" stuff, if distributing the baggage of a framework is your concern. I know this isn't really the same as native AOT though. I'm targeting many of our applications to EL7 (eg. CentOS 7.x) distributions as standalone RPMs that install on a clean Linux box and work without installing .NET Core. I install the application to /opt/my-widget and symlink the main binary to /usr/bin.

Awesome, elaborate a little bit if you can.

Basically this:

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

In my current project I code about 70% C++, 30% C#.

If you don’t need fancy stuff, you can stick to whatever .NET version is built into your target Windows (e.g. 4.5.1 for Win 8.1, or 4.6 for Win 10), and you should have zero issues with deployment (if that’s why you don’t like VMs). While technically a VM, .NET is very good one, and the quality of its runtime and framework is outstanding.

OTOH, I can’t recommend .NET AOT compilation. I used similar MS technology called .NET Native. They have the stuff for a couple of years for Windows 8 Store & UWP platforms. I found and reported multiple bugs with the technology, especially in the area of unmanaged interop. They eventually fix their bugs, but they wasted quite a bit of my time, and I wonder how many more are going to be there.

http://stackoverflow.com/q/34187890/126995

https://github.com/Const-me/EsentSerialize/commit/ea2cc7be58...

The third one (only reported via e-mail), .NET Native fails to marshal custom COM interfaces implemented in C# classes to C++ libraries, at least on ARM for Win10 IoT.

You don't need to wait for CoreRT when there is Mono -aot.

Does that mean .Net 2.0 WinForms applications will work on Linux now?

WinForms is not part of the .NET Standard API surface. See https://docs.microsoft.com/en-us/dotnet/api/?view=netstandar...

.NET Core does not include any UI libraries.

Nothing has changed with regard to WinForms on Linux. You can continue to use Mono's old WinForms implementation, but should not expect a perfect experience.

The answer is obviously no. .net core is mainly about web apps and console apps. There is no support for desktop applications.

Reply on news.ycombinator.com