
Announcing .NET Core 2.0 Preview 1 - runesoerensen
https://blogs.msdn.microsoft.com/dotnet/2017/05/10/announcing-net-core-2-0-preview-1/
======
runesoerensen
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-...](https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/)

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

~~~
dvcc
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?

~~~
avtar
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.

~~~
JBReefer
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.

~~~
lloydjatkinson
> 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.

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

~~~
oblio
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](https://github.com/dotnet/corert/milestones)

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

~~~
0xFFC
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.

~~~
account1984
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.

~~~
0xFFC
Awesome, elaborate a little bit if you can.

~~~
oblio
Basically this:

[https://docs.microsoft.com/en-
us/dotnet/articles/core/deploy...](https://docs.microsoft.com/en-
us/dotnet/articles/core/deploying/index#self-contained-deployments-scd)

[https://docs.microsoft.com/en-
us/dotnet/articles/core/deploy...](https://docs.microsoft.com/en-
us/dotnet/articles/core/deploying/deploy-with-cli)

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

~~~
sandyarmstrong
WinForms is not part of the .NET Standard API surface. See
[https://docs.microsoft.com/en-
us/dotnet/api/?view=netstandar...](https://docs.microsoft.com/en-
us/dotnet/api/?view=netstandard-2.0)

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

