
.NET 5 - benaadams
https://devblogs.microsoft.com/dotnet/introducing-net-5/
======
lol768
I'll be honest, as much as I love the improvements with .NET Core/.NET
Standard, Microsoft's branding strategy leaves _a lot_ to be desired.

vNext has already been historically used in the context of ASP.NET to refer to
ASP.NET (not to be confused with ASP.NET MVC) v6. We restarted the versioning
back with ASP.NET Core, now on version 2. Entity Framework used to be a .NET
framework component but is now standalone, and has a Core version? Does Blazor
(or is it Razor Components now) share the .NET branding?

Separate to the web stuff, we have the .NET platform - .NET framework is the
non-cross platform version for which we're on version 4, but it implements
.NET Standard v2 along with .NET Core, which has a Linux runtime. Mono also
implements .NET Standard v2 and has a Linux runtime.

I remember many years ago when we also had Microsoft .NET Passport.. which was
completely unrelated to everything else that I've mentioned related to the
.NET brand.

And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET
drop this Core branding too? Is it just me, or is this all incredibly
convoluted?

~~~
phillipcarter
> And now we have .NET 5 which is neither Framework nor Core

Just to note, the blog post explicitly says that .NET 5 is the next version of
.NET Core. It's where .NET Core is going, and given that so much more of the
.NET "picture" is being realized with it, the name is changing to be more
reflective of the fact that it's not really a "core" (small) thing anymore.

~~~
pknopf
I look at this ".NET 5" thing as a PR move to end full framework.

"We aren't ending full framework, we have .NET 5!"

If you are developing new apps in full framework, you are doing it wrong.

~~~
tstrass
If you're developing an application with a Windows desktop GUI, you're still
doing it on full framework (WPF, WinForms, UWP). They're folding that into
.NET 5, and I haven't seen anything indicating that they see that as "doing it
wrong". This is only one case of developing for full framework, but it's a big
one. I imagine any other cases where the developer community really needs full
framework capabilities that still aren't ported to CoreCLR, they'll fold that
in just the same as with the UI frameworks, as a Windows-specific capability.
Maybe they end up sunsetting more than I think, but for now this seems more
like consolidating Core and Framework than ending Framework.

------
MikusR
"There will be just one .NET going forward, and you will be able to use it to
target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and
more."

~~~
oldjokes
This is remarkable, and impossible to predict from the Microsoft of 10 or 20
years ago. Satya seems to be the rare visionary CEO of a megacorp, instead of
just defaulting to a defensive and reactionary stance like most other leaders.

~~~
acomjean
I don’t know. I think they’re still the same at the core, they just do enough
to try and stay relevant.

Office for Linux would be easy, but that’s not going to happen.

My companies online outlook shows that MS is adding clones of all the tools
(slack/trello).

They’ve been successful and monitizing in this new era

~~~
Scuds
> Office for Linux would be easy, but that’s not going to happen. They're
> rewriting Office in React Native so Windows, OSX, and mobile ports will have
> a lot more in common.

But "Desktop Linux" will always be a million support headaches for no market
share; which begs the question "Dear Lord, why?"

~~~
cm2187
And the only way to build market share is through cannibalization of windows
licenses. Not in microsoft's interest. If you hae a proper office for windows,
I bet many companies would consider seriously switching to Linux.

~~~
scarface74
Office has been available for Mac for well over two decades. There are so many
more reasons for companies preferring Windows on the desktop than just Office.

~~~
cm2187
I think there _were_ so may more reasons. But what I see is all internal apps
moving to be web based. 5 more years and Office is really going to be the last
thing tying up corporates to Windows.

~~~
AnIdiotOnTheNet
Call me when Linux has anything that works as well as AD.

~~~
yellowapple
It does; it's called AD. :)

The _actual_ problem is the lack of Group Policy support (or even a viable
equivalent - preferably one that's cross-platform).

------
majkinetor
I have extensive XP with .NET Core 2 in production on huge services with 1M+
users - we started making some stuff before 1.0 and had it in production after
having few sessions with local MS.

WebAPI, APS.NET Core, Pwsh, C# 7... I dont work for MS, but that is some
seriously good tech stack. Performance is amazing too. I highly recommend it.
Worked in 50+ environments so far but this is top stuff. MS really nailed it
this time. No, don't tell me that JAVA is comparable to C# in elegance, that
linux dudes had python/ruby/perl/whatever before Powershell etc.

The only problem we had so far was with the Oracle db drivers which were non
existent until several months back, but that is on Oracle... which sux more
and more each day - commercializing java for example will just give a boost to
.NET now, a lot of it - who at Oracle made up such decision escapes me, but
maybe he works for MS.

~~~
pickle-wizard
Do you run .Net Core on Windows or Linux?

I have a project in the early design phase that I was thinking of going with
.Net Core on Linux. I've thought about going with Java, but with all the
recent Java licensing changes don't think I want to go that route anymore.

~~~
majkinetor
I currently run on Windows servers, some of which are Core. Tried nano but its
terrible as there is no package manager and no support for msi files. If you
install anything in docker it takes GB's so we used VM's for bakcend/frontend
running Windows Server 2016 behind IIS/kestrel/nginx and every other
supporting tech on Linux (not core). One of the reasons to use Windows was Sql
Server but mostly PowerShell which we do all automation in. Backend service is
used to register invoices for entire country and it has 1M+ users, we have
60-100 logins per minute and 500+ concurent actions. Backend is served by
single server (!) and never gets more then 10% CPU load and 20% memory with
that load. I am amazed honestly. Zero dev fucktitude (once we ditched Angular,
but that is another story). Almost zero downtime (30-50s to build and deploy
with db migrations).

Now, we use Linux alpine docker containers, use postgre instead Sql Server and
pwsh with Invoke-Build to run CI/CD stuff. Sworm for orchestrations and
compose for local. Have 2 incoming country-level services this year for
production. Currently on dev/stage it works really fast but load is trivial.

We did a lot of performance test on Windows and achieved 1.5-2K req/s with
hello world and our setup on IIS/kestrel. Did no test for linux variant so
far.

> I've thought about going with Java,

Java compared to latest C# is like ... Clojure to VBA. No brainner really,
plus Oracle (sure, there are alternatives).

Also, entire Java enterprise stack is overengineered beyond repair. I need 77
classes for basic stuff. Take .NET core you wont regret it.

~~~
tracker1
I assume your docker taking GBs above is for Windows Containers? Also, most of
that overhead is first use, updates and parallel similar containers are much
smaller. Also, as you mention, alpine containers are what I'd consider "just
enough" when wanting to diagnose an app in a container.

I've found that .Net Core on Linux and in Windows are close enough that
scaling should be the bigger concern. Unless you're tethered to windows, the
broader tooling is much more mature with Linux containers/pods.

~~~
chupasaurus
.Net has some caveats with GC: Server GC preallocates heap per CPU core so if
you have 8+ server it could be a waste of RAM if app uses less than 1GiB. We
are tinkering with microservices on .Net Core 2 in k8s and came up with using
WS mode with clearing unused allocated memory on health check calls which is
dirty but working trick.

On the Java side though there is a hack in JRE which checks if JVM runs inside
a Docker container in order to not get out of memory limit by cgroup.

~~~
GordonS
I believe the are changes coming in .NET Core 3.0 to fix the OOTB server-GC
situation.

Of course for now you always have the option of enabling desktop GC instead

------
bob1029
I am very pleased with the direction Microsoft has been moving the last few
years. Every release of .Net has incrementally made our lives easier.

We are already on top of .Net Standard/Core 2.0 and are building successfully
against 3.0 prerelease targets without modification. I would anticipate the
move from Core 3.0 to .NET 5.0 would be trivial for us, and as long as self-
contained deployments are still around in 2020 our build & publish pipeline
won't know the difference (aside from msbuild & SDK updates on Jenkins).

Exciting times ahead.

------
badsectoracula
So, does this also replace/update the .NET Framework that is bundled with
Windows 10, meaning that you can release a .NET EXE and ask people to use the
latest version of the .NET like you can release a .JAR and you can ask people
to have the latest version of Java, or you have to bundle the entire runtime
(be it via a fat compiled AOT or regular bundling) with your application?

I ask because one of the positive things about .NET Framework 4 is that i can
create a tiny .EXE and give it away and expect that people will have the
runtime to run it since it is already part of Windows.

~~~
Arnavion
From the 3.0-preview5 announcement:

>You can now publish a single-file executable with `dotnet publish`. This form
of single EXE is effectively a self-extracting executable. It contains all
dependencies, including native dependencies, as resources. At startup, it
copies all dependencies to a temp directory, and loads them for there. It only
needs to unpack dependencies once. After that, startup is fast, without any
penalty.

[https://devblogs.microsoft.com/dotnet/announcing-net-
core-3-...](https://devblogs.microsoft.com/dotnet/announcing-net-
core-3-0-preview-5/)

~~~
badsectoracula
This is for .NET Core 3, not for .NET 5. While .NET 5 might provide the same
tool, it doesn't answer if it will _also_ provide a .NET Framework 4-like
functionality where the .EXE relies on a runtime already installed on the
user's system and if that framework will be something the developer will need
to provide and/or be part of Windows 10 like .NET Framework 4.

~~~
Arnavion
And .Net 5 will be the release after .Net Core 3, so I assume they won't go
ahead and remove the feature for it.

~~~
badsectoracula
Sorry, i edited my message above after you replied it to add a bit of more
detail what i mean.

~~~
Arnavion
Ah, got it. You want to be able to ship something that relies on an existing
installed runtime and _don 't_ want to bundle the runtime with your
executable.

~~~
cm2187
Me too. Requiring to run all executable with a command line is a major
inconvenience. And by choosing ".dll" as an extension it is not even possible
to assign the extension to dotnet as a default application like you could with
a jar file. And if you want self-executing binaries you not only have the
version problem you mention, but you also have to bundle all sort of
assemblies. And there doesn't seem to be anything like ILMerge for .net core
assemblies to merge them into a single file.

~~~
shawnz
What you are looking for is called a "framework-dependent executable" (exe
file with no framework) rather than a "self-contained deployment" (exe wrapper
for dll file with framework included) or a "framework-dependent deployment"
(dll file with no framework)

------
bellp1234
Any word on F#? Last I checked there wasn't any REPL still and type providers
weren't working.

~~~
enricosada
The F# repl (FSI as fsharp interactive) works in .net core 3.0 preview
already, you can do `dotnet fsi` to run it

Type providers works in general, but depends if the type provider library was
updated to use latest type provider sdk. Also generative type provider may not
works, erasing works

~~~
phillipcarter
Just adding to Enrico's post here, Type Providers have been fully supported
since .NET Core 2.1; some libraries just may not be updated yet.

`dotnet fsi` is planned to be fully released later this year with the .NET
Core 3.0 release.

------
mikequinlan
I was really excited to see this; finally a consolidated .NET. Then I read
this...

Taken together, the .NET Core and Mono runtimes have a lot of similarities
(they are both .NET runtimes after all) but also valuable unique capabilities.
It makes sense to make it possible to pick the runtime experience you want.
We’re in the process of making CoreCLR and Mono drop-in replacements for one
another. We will make it as simple as a build switch to choose between the
different runtime options.

~~~
manigandham
Mono is a large part of mobile and Unity for gaming. It's not going to
disappear anytime soon and they can't go back to it being completely separate.
This is the best compromise to keep the runtimes the same but share as much as
possible between them.

------
stusmall
"Java interoperability will be available on all platforms."

Where can I find more details on this?

~~~
runfaster2000
There are not really any yet. We intend to take the Java interop that Mono
already supports, improve it as needed, and make it available to other
scenarios beyond just Android. If there are certain things you would like to
see, I'd love to know.

~~~
stusmall
I'll read up on how Mono handles it. I've never done too much .NET and I'm a
recovering JVM dev, I was just asking out of curiosity since that is a pretty
thorny feature to tackle. I can think of a number of dangers/shortcomings with
any approach I can think of.

------
Dayshine
Does this spell the end of .NET Standard?

And does this explain why they don't seem to care about making .NET Standard
versions at all logical to developers (e.g. making a major breaking change,
not supporting .NET Framework, to .NET Standard in a minor version)?

Edit: And before someone says ".NET Framework is choosing not to support .NET
Standard, you shouldn't version based off implementations but off changes in
the API": That only works if you have many implementations, .NET Standard has
3 major implementations! Losing 33% is pretty significant :)

~~~
runfaster2000
We haven't made a decision on .NET Standard yet, in terms of what its role
will be going forward. Major point is that its forward-looking role will be
significantly diminished with this plan.

~~~
Someone1234
You guys should seriously consider the mental load all of this rebranding is
having on your community. You have too many brands, too many names, and too
many seemingly overlapping ideas.

I want to see .Net Standard die, not because of the technological merits of it
or problems, but because you guys have created such a confusing mess and .Net
Standard is perhaps one of the worst examples.

.Net Standard seemingly exists to consolidate compatibility between
Core/Framework/whatever, but with you consolidating them under the "Framework"
branding anyway there's no reason it should exist except to confuse further.

Either something is or isn't .Net 5 compatible. The end.

~~~
13jadkins
This was the entire reason I stopped being a .NET developer. Made the jump to
Ruby a year ago.

~~~
pjmlp
Because handling gems compatibility issues and monkey patching is so much
better experience.

------
sergiotapia
I haven't used .NET since 2011, if you're in the same boat take a look at C#
today. They're grabbing all the best features of other languages and making it
their own, WHILE also allowing you to deploy static binaries to _any_ major
platform.

Write C# code purely in VSCode or Rider, compile to all three platforms while
on a Mac, and run your code in Linux. All from supported, non-hacky features.

Why use Go if you can use C#? C# is now incredibly compelling. The C# of today
is not the C# of 6 years ago.

~~~
Xixi
Goroutines and Async-Await are two very different takes on the same problem.
In that regard, preferring Go over C# is an incredibly good reason to keep
using it instead of switching over to C#. Choice is good, I prefer more
languages than fewer.

~~~
GordonS
I know essentially nothing about go - could you explain simply what goroutines
are?

~~~
Xixi
I'm far from being an expert at Go, but I will try: goroutines are green
threads (very light threads, if you prefer). The main difference between async
calls and threads is that threads remove the distinction between synchronous
and asynchronous code.

In C# or Python 3, each function is colored as either sync or async. You can
quite easily call an async function from a sync context, but doing a blocking
sync call from an async context is forbidden (although possible).

In Go there is no such distinction: you just write your functions in a
straightforward fashion, as if everything was synchronous, and then wrap
whatever you want to run in the background in a goroutine. If you don't need
the return value from that function, it is has simple as issuing:

    
    
      go my_func(param_a, param_b, ...)
    

Note that goroutines are green threads, not OS threads, so you can easily
spawn many tens of thousands of them without bringing your system to a halt.

~~~
tamrix
Async is to deal with io not for all concurrency in general. It uses
interupts, not threads. Although the implementation can use threads for
optimisation, it is not the point. If you're waiting on a network socket or
reading lots of files, you don't need to spawn a new thread for each item. You
can instead schedule a task to run one an interupt is received.

~~~
Xixi
You are entirely correct. My sentence "The main difference between async calls
and threads is that threads remove the distinction between synchronous and
asynchronous code." is pretty weird: I wasn't talking about threads in
general, but green threads as used by Go (i.e. Goroutines) in particular.

The idea that I wanted to express is that, very broadly, there are two ways of
dealing with concurrent io. One is to deal with it explicitly at call site,
using some variation of async/await semantic, futures, promises, or just
callbacks. That's the C#/Python 3.4+/javascript way of doing it. Although
implementations vary wildly between these languages, the core idea remains the
same.

The other way of dealing with concurrent io is using green threads (or related
concepts like actors) as in Go, Elixir, Python with gevent, etc. IO calls
don't look special (no await, no yield, no special keyword, no callback), that
is to say they behave like any other function call (although the
implementation of these io calls is non-blocking to allow other green threads
to run). Concurrent io from the programmer perspective is achieved simply by
spawning many green threads/actors.

I personally find green threads easier to reason about than async calls,
especially in the long run when maintaining large software.

------
oaiey
I think there are some developers who would consider .NET 5 a huge breaking
change. .NET (Framework) 4.8 looks like the predecessor but has features
(rightfully) not available in .NET 5.

I like the vision but hate the name. .NET Core 4.0 would have done it. When
you market software engineers stick with patterns. This looks like a lot of
managers have feedback to stuff they did not understand in the first place.

~~~
cspierre
I love the name. The numerous .Net monikers are confusing. Framework, Core,
Mono... each with overlapping support for various frameworks and platforms. I
expect new .Net developers to be overwhelmed trying to figure out the
differences, as I was.

The monikers were misleading. This feels clean, looking forward to it.

 _Does "Core" mean core functionality? Then what is ".Net Standard"? Is .Net
Core cross platform or Mono? Why can't I use .Net Core library with Xamarin?
Is Xamarin .Net Mono? Should I use .Net Core Winforms or .Net Mono?_

------
dr_faustus
Funny how this announcement comes the same week Oracle decided to kill Java
EE. MS has always been good to it's developers and broadening the .NET
platform this way makes one really consider to give it another look. Oracle in
the other hand basically spreads FUD about their own platform, even though
they seemingly don't even care about it anymore.

~~~
victor106
I agree. Shame on Oracle.

J2EE is widely popular and continues to have a vibrant community. Oracle just
doesn’t have the vision of how to encourage and mature that community and turn
it into the proverbial golden goose. All they want to do is kill it to get all
the eggs today. They can just copy/learn Microsoft’s strategy and come out on
top.

------
kdtop
For the newbie here, can someone tell me if this is open-sourced? Many are
fearful of building on a MS platform in case they change their minds in the
future etc?

~~~
astine
There are some open source components here, but I don't think the .NET
platform as a whole is being moved to open source. The core compiler and
runtime are open, but some of the most popular libraries and frameworks are
still closed, it looks like.

~~~
paavohtl
There isn't much that hasn't been open sourced in the past few years: The
runtime, standard library, C#/F#/VB compilers, ASP.NET, Entity Framework,
Xamarin, PowerShell, Winforms, WPF are all open source or (in the case of WPF)
being open sourced.

[https://github.com/dotnet/](https://github.com/dotnet/)

~~~
southerndrift
How about the C# debugger?

~~~
StaticRedux
Roslyn is open source.

~~~
ygra
Roslyn is the compiler. There's not much of a debugger in it, is there? I
mean, I guess the debugger will use Roslyn to parse watch expressions and
evaluate things in the Immediate Window, but beyond that I think debugging is
handled by something else.

~~~
nathanaldensr
I think the debugger is Visual Studio itself.

------
lwansbrough
This seems like it would be a prime opportunity to introduce UWP applications
to macOS and Linux. That would be a welcome alternative for developers looking
to develop high quality native + cross platform applications.

~~~
ocdtrekkie
.NET desperately needs a first-party supported solution for cross-platform
desktop apps. I was searching this news for any hint of that, and don't think
we're going to see it yet.

I am unsure if they would try to push UWP to those platforms, or focus more on
expanding Xamarin which is already cross-platform. I know WinForms and WPF are
considered far too dependent on Windows proprietary APIs to ever be officially
supported elsewhere, I assume UWP is the same.

~~~
pknopf
I would rather stand on the shoulder of giants and use Qt.

You can use .NET Core with Qt/QML.
[https://github.com/qmlnet/qmlnet](https://github.com/qmlnet/qmlnet)

~~~
ocdtrekkie
That looks pretty cool. I've also seen Avalonia, which is a more .NET-focused
approach, meant to be very similar to WPF:
[https://github.com/AvaloniaUI/Avalonia](https://github.com/AvaloniaUI/Avalonia)

But the main issue for me is that Microsoft just needs to pick something, and
say "this is how to write cross-platform desktop apps in .NET", and support
it. I don't really care what it is, they just need to have one.

------
earenndil
Interoperation with java, swift, and obj-c is interesting. I wonder if they
have an actual jvm, or they're just implementing java-the-language?

~~~
runfaster2000
Like this: [https://docs.microsoft.com/en-us/xamarin/android/get-
started...](https://docs.microsoft.com/en-us/xamarin/android/get-started/java-
developers#interoperating-with-existing-java-code)

------
pjmlp
We just started a new project on .NET Framework 4.7.x, because not everything
that we care about is available on .NET Core, not even with the upcoming .NET
Core v3.0.

Lets see how .NET 5 will sort out the current state of affairs.

In any case, it is a welcome change to sort out the mess that the whole WinRT
and .NET Core 1.x have brought out.

~~~
bob1029
I am curious what specific features you are using in .NET Framework 4.7x that
are not accessible in .NET Core.

We use 'legacy' APIs like System.Drawing and System.DirectoryServices from
.NET Core without any issues today - [https://docs.microsoft.com/en-
us/dotnet/core/porting/windows...](https://docs.microsoft.com/en-
us/dotnet/core/porting/windows-compat-pack).

Although, we exclusively target Windows platforms right now (RID == win-x64).
We are considering replacing these Windows-only deps with cross-platform
alternatives in the future (e.g. Novell LDAP and Mono drawing) so that we can
start looking at Linux as another hosting option.

I have even had reasonable success with retargeting 3rd party libraries to
.NET Standard 2.0 without much coding effort. It's mostly just *.csproj XML
soup management.

~~~
ToFab123
<I am curious what specific features you are using in .NET Framework 4.7x that
are not accessible in .NET Core.

Windows Communication Foundation (WCF)

~~~
ToFab123
To expand on this. As I understand Microsoft has started to create a new
version of WCF for .NET core (or 5 as it is called now). I should a multi-year
development project to do this, because it can no longer be "Windows"
Communication Foundation since it also must work on Linux.

They same goes for EWT tracing which is the logging mechanism you can use.
That also has to be cross platform.

So for some years to come, I (on some projects) are "stuck" with .NET 4.X
until WCF and EWT has been re-architectured.

~~~
pjmlp
Not at all, they just made it official that we are forced to rewrite those
apps.

~~~
ToFab123
Since much of the banking world is heavy users of WCF, Microsoft has no other
option that to implement WCF in. Net 5 unless they want to loose the banking
industry. I did come across a post from one of the WCF products managers who
said that they are working on a cross platform solution but it will take some
(much) time before that has been completed. Cannot find this post, but I
consider it safe to say that WCF for .net 5 is coming and that I am stuck util
it does as there really is no alternative to using WCF

------
kumarvvr
Off the topic, but I come from Python / Django / Flask. (Have experience
programming desktop apps with .NET 4 and C#). I just don't _get_ web app
development with asp.net core.

Is there a ground up tutorial, concept-wise, about how asp.net works?

~~~
oaxacaoaxaca
I’ve gone straight to the official Microsoft docs multiple times to try and
get the same experience as when you read the Django documentation, but it’s
just not there. Django’s docs explain the what, the why, and more. The
Microsoft docs just have the what.

I want to love .NET Core development because I love Microsoft’s open source
effort, but the support (or lack thereof) from the documentation is quite the
hindrance.

~~~
tamrix
The docs are open source too. There's countless blogs and books. Visual Studio
is a bit easier for some to get started than vscode. It's free.

Maybe your struggling in other areas?

~~~
oaxacaoaxaca
Not "struggling in other areas" but thanks.

Been using VS and VSCode for a long time.

Don't care that the docs are open source.

My issue is that I guess I have high expectations for the official docs of a
platform/framework/library/whatever. You shouldn't have to buy a book or read
a random blog to find critical information on core functionality. The official
docs should provide that, and Django is a great example. It includes how to do
things, why things are the way they are, how to customize workflows, best
practices, pitfalls, and on top of all that the source code is super easy to
read and understand.

The pages at docs.microsoft.com are mostly just basic walkthroughs that leave
me with a lot of questions. And the .NET Core source code is not nearly as
readable.

It's getting better though. And I don't mean to take jabs at Microsoft because
I truly do appreciate how much they've done in open source over the last few
years, especially with VSCode.

~~~
nlawalker
Do you have a concrete example or two from the Django docs that you consider
to be representative? Not doubting you at all; honestly just curious to see
what you're looking for in documentation.

Microsoft docs are constantly under revision, including general improvements
(not just reaction to changes), and the writers are very receptive and
responsive to feedback.

(I work at Microsoft on docs, but not on the ASP.NET Core docs)

~~~
oaxacaoaxaca
Hi. Sure thing.

First off, thank you for what you do. Microsoft is kicking ass these days and
I don't want to sound like I'm unappreciative or unimpressed with what you
guys are doing.

A quick example could be user authentication:

[https://docs.djangoproject.com/en/2.2/topics/auth/default/](https://docs.djangoproject.com/en/2.2/topics/auth/default/)
[https://docs.microsoft.com/en-
us/aspnet/core/security/author...](https://docs.microsoft.com/en-
us/aspnet/core/security/authorization/secure-data?view=aspnetcore-2.2)

The first thing I see when scrolling down those pages is that the Django page
is ~90% descriptive text and ~10% code. The ASP.NET page is the opposite: ~10%
descriptive text and ~90% code.

Obviously that's not the best metric but I need to get off HN soon so that's
the best I have for now :)

In any case, this could support my earlier claim: Django docs give not just
the "what" – they also provide the "why", along with super useful
background/supporting information, and even alternative approaches (e.g. in
the "Limiting access to logged-in users" section there are at least five
avenues you can choose from to meet your needs).

That was the quickest example I could find. Sorry it's not more substantive.
I'll post again later if I find something that could be more helpful.

And again, I really appreciate what you guys are doing and don't mean to sound
like I'm sending any negativity in your direction <3

~~~
nlawalker
No negativity received on this end at all!

I definitely see what you're saying - that section of the ASP.NET Core docs
drop straight into a top-to-bottom code-driven tutorial, whereas the Django
docs go concept-by-concept. This is great feedback, so thanks!

If you get a chance, check out Microsoft Learn (microsoft.com/learn) - we're
working on _guided learning_ as opposed to _documentation_. Most of our
content is interactive and task-based, but we try to ground the interactivity
with conceptual information, context and scenarios. Much of the technical
content published to date is Azure-focused, but we're growing other topics,
including ASP.NET Core.

~~~
oaxacaoaxaca
Hey thanks! I hadn't gone through that site, but I'm reading
[https://docs.microsoft.com/en-us/learn/modules/build-web-
api...](https://docs.microsoft.com/en-us/learn/modules/build-web-api-net-core)
now. Looks great! Nice work!

------
magnat
Since planned release date is well after Windows 7 EOL date (2020-01-14), I
wonder if .NET 5 will be released only for Windows 10.

~~~
max76
Windows 8 extended support doesn't end until 2023.

~~~
ygra
Isn't extended support only for security updates?

------
lazulicurio
I'm cautiously optimistic.

> Moving to a single .NET implementation raises important questions. What will
> the target framework be? Will NuGet package compatibility rules be the same?
> [...] How does writing code for a specific architecture work? [...] We are
> working through these issues now and will soon be sharing design docs for
> you to read and give feedback on.

This, however, is my biggest worry. Between runtimes, content files,
analyzers, native references, asset visibility rules, etc., packaging has
become kind of a mess. I'd love to see a move away from monolithic packages,
but IDK if that's on the table. Fingers crossed.

------
majkinetor
Oh, small lies, nobody noticed...

GUI is not cross-platform in .NET 5 which is not visible on the graphic.

~~~
cspierre
No Lies! Mono already supports cross platform winForms, and recently the
ability to embed Xamarin.Forms views in both mobile and desktop.

~~~
basetop
But isn't winforms pretty much legacy? Microsoft has been encouraging the use
of WPF.

~~~
majkinetor
Xamarin.Forms is not Win Forms AFAIK.

Legacy or not, Win forms would be better then nothing. For that to happen GDI+
need to be ported to core and for WPF to happen DirectX needs to be ported to
core. Its all into UWP now.

So I guess it will not happen soon. MS should reboot IMO.

~~~
ygra
GDI+ is available on .NET Core as Mono.Drawing, I think. Windows Forms is tied
to a lot of Win32, though, so GDI+ alone isn't really enough.

------
euroclydon
The more they use the word "throughput" the less I understand it.

------
crispyambulance
I'd just like to know what do they mean by ...

    
    
        > Java interoperability will be available on all platforms.
    

What, is that possible now on some .NET platforms? What does it mean? That I
can use java classes in my .NET application??

~~~
oaiey
Xamarin technology to bridge between .NET and the Android stack. This is old
tech re-packaged, bringing Java classes and their APIs to .NET.

------
merb
I really love the direction. Finally a single platform AND java compat. this
is so good.

------
polskibus
What does it mean to standard ASP .Net (not core)? Will I be able to run all
the enterpisey apps that use ASP MVC and WebForms on Linux in 2020? And if not
on Linux, then will WebForms / old MVC work on NET 5 on Windows?

~~~
scarface74
No. The legacy stuff will be ported to be compatible with .Net Core but will
still be Windows only.

~~~
jsmith45
But presumably only the Core 3.0 WCF/Winforms "most things work, but in all
likelihood your million+ line of code app will have all sorts of little things
that won't work".

Presumably if you are using any of the following heavily in your applications,
you will never be able to run on .NET 5 without major porting effort (I.E.
reworking everything to avoid these):

* Remoting

* C++/CLI or Managed-C++

* App domains

* code access security

* ASP.Net Web Forms

* Exposing registered COM interfaces from .NET code for access from Win32 code.

* WCF Servers (Technically, nothing prevents somebody from porting this, since WCF is basically pure managed code, and its tricky Proxy related code is already ported as part of the client code. It is just that Microsoft has no plans to bother with this.)

Will SQL Server upgrade its .NET support for .net 5? (Potentially breaking
compatibility with certain currently supported use cases)?

I'm guessing IIS Managed modules will never upgrade beyond .NET 4.X.

~~~
wvenable
It's not like they have to re-implement all the code for these things; the
majority of this code can just be moved over as-is from .Net framework to .Net
core on Windows with minimal modification.

I'd be surprised if the goal isn't 100% compatibility. If Microsoft can get
Linux applications to run on Windows, they can probably get .Net applications
to run on .Net.

~~~
jsmith45
Remoting/app domains/Code access security were ripped out of the .NET Core
codebase, and there is really not much of a chance of them returning. The
CoreFX codebase has systematically removed all the code needed for things to
safely work with those features, and re-implementing them would be unfeasible.

As for webforms. Well, the whole hosting model for IIS worker processes was
based on appdomains. Further, w3wp.exe has special code for loading and
integrating with the Framework, enabling managed modules. This is the whole
System.Web.dll concept. Microsoft really does not seem to want to put in much
effort to fix that.

Since Microsoft always recomended hosting WCF services in IIS, which therefore
relied on the whole System.Web.dll mess which I think is a large part of the
reason thy don't want to port that.

That said, other than replacing XML configuration, self-hosted WCF services
should be pretty easy for them to port.

~~~
merb
app domains basically now have a better alternative with Application Parts or
for the heavy lifting AssemblyLoadContext ([https://docs.microsoft.com/de-
de/dotnet/core/tutorials/creat...](https://docs.microsoft.com/de-
de/dotnet/core/tutorials/creating-app-with-plugin-support))

~~~
jsmith45
AssemblyLoadContext with assembly unloading is not at all compatible with .NET
Framework 4.X, which can be a pain if you want to gradually migrate stuff.

Also it does not have anywhere near the same level of isolation, which is part
of what System.Web.dll was using them for. Would it be possible to it in a
system.Web.dll port? Certainly, but you would be changing the semantics enough
that some applications would notice the difference, and probably not in a good
way.

~~~
merb
yeah I mean unloading is not even that good without a .net core 3.0 preview. I
think that in 5-10 years new stuff will emerge based on AssemblyLoadContext,
maybe even some kind of OSGi just a little bit easier. Some examples are
really promising and AssemblyLoadContext does not have the same problems as
Java solutions. (duplicate Class Files, etc...)

the only thing that is missing is some kind of security related stuff.

------
Zenst
Interesting but as there is a 3.1 LTS version due before this comes out and
this 5.0 release is not LTS, with any of those features not going LTS until
6.0 in Nov 2021.

So that kinda diminishes my initial excitement, much could change in a short
period and we are talking over 2 years until any additional features becomes
set in stone with LTS support. So for me, it's probably not looking at until 6
months before LTS release. As is the case with many others.

But some good changes - a rebrand would of cut of any confusion and historical
hangovers. As between now and Nov 2021, much could change.

------
sjs382
I'm sure I'm not alone in thinking that the .NET ecosystem is super confusing,
coming as a developer outside of that ecosystem (mostly web).

I'm a JS, Python and PHP developer who sees a majority of jobs in my area as
.NET centric. To this end, I'm interested in familiarizing myself with .NET
[1] but I'm totally at a loss wrt/ where my entry point to the ecosystem
should be.

[1] Insofar as starting a new small project or re-implementing an old side
project in .NET as a learning process.

------
jeswin
The most interesting piece of work happening in the .Net world is actually
CoreRT (which is already beta quality), which lets you write fully native apps
with access to the large .Net ecosystem. For many, it could be an alternative
to Go/Rust. c# is a more capable language that Go, and easier than Rust - a
particular sweet spot.

Instead the announcement was primarily about unrolling the version mess
created over the last few years.

------
sqldba
As you can see from 300+ comments at the time of writing, the post is entirely
unclear about what's happening seeing as everyone still argues about it.

My read of it is that .NET Core becomes the new .NET, not that .NET Core has
parity with the existing .NET.

Specifically I can't just retarget my existing projects against .NET Core (or
the new .NET) and have them just work.

------
PieUser
Damn, hard to believe 2020 is just next year!

------
darkstar999
Good. It's so confusing right now.

~~~
kgwxd
It will still be confusing. At some point you'll need a library that doesn't
support it. ".NET" promised backwards compatibility. Now, old ".NET" stuff
won't work where you'd previously expect it to. Everything was quite clear
when these 2 incompatible platforms had separate names. It's like merging Java
and JavaScript "for clarity".

~~~
dragonwriter
> ".NET" promised backwards compatibility.

Except for 2.x-3.x, .NET Framework didn't provide backward compatibility
across major versions, so a break at the 4.x-5.0 transition would be in line
with .NET Framework history even if .NET 5 was viewed as .NET Framework 5.
Which seems to be why the version of what is basically .NET Core after .NET
Core 3.x is .NET 5, so it fits expectations whether viewed as a .NET Core
version or a .NET Framework version number.

Enterprise will no doubt keep legacy .NET Framework 4.8 around for legacy
apps—the same way they do Framework 1.1 and 3.5.

> It's like merging Java and JavaScript "for clarity".

Not really. .NET Core can be viewed as just a production-ready but not feature
complete early release of the next major version of .NET Framework, which
involved major reengineering, and which will be released as .NET 5 when it is
feature complete.

------
maxxxxx
Sounds good. Let’s hope they won’t change their mind until release in 11/2020.

~~~
oblio
It would be kind of dumb on their part. They're competing with Java, Golang, a
reborn C++, Python, Swift, Rust, etc.

They badly need .NET to get adoption outside of Windows, which is a stagnant
platform regarding dev adoption.

~~~
maxxxxx
“It would be kind of dumb on their part. ”

Agreed. However they have a long tradition of doing the right thing and then
killing it immediately with stupidness and arrogance

~~~
oblio
They were knocked down a peg when they completely missed mobile.

------
reasonablemann
Coming from mainly python I must say I'm extremely impressed with .net core.

I think my mac days would be over if Windows had better font rendering and a
usable terminal -- even ConEmu leaves a lot to be desired.

~~~
manigandham
A new terminal is coming:
[https://news.ycombinator.com/item?id=19840447](https://news.ycombinator.com/item?id=19840447)

------
qwerty456127
Still of limited usefulness as long as WPF is not cross-platform.

~~~
tracker1
See [https://platform.uno/](https://platform.uno/)

------
vturner
"Java interoperability will be available on all platforms" I wonder if we will
see a resurrection of the long gone Scala on CLR?

------
a3b2c1r46
Is it fair to say after 30 something years the basic is dead? I dont see any
mention of it on any of the posts I read about .net 5

------
polskibus
Will VS 2017 support NET 5 ? Will VS 2019 do it ? Or will I need to buy yet
another VS upgrade to enjoy it in full ?

~~~
dragonwriter
> Or will I need to buy yet another VS upgrade to enjoy it in full ?

Don't most developers using non-Community VS get it via a Visual Studio
subscription, either annual Standard (formerly, MSDN) ir monthly Cloud, both
of which also include current and former Visual Studio downloads?

------
philonoist
How does this compare to the Java ecosystem in terms of enterprise adoption?

------
1000010110
Sorry for my ignorance but how is .NET 5 different from Standard (2.0)?

~~~
tracker1
My take on this, is it means that .Net Framework and Mono will cease as
separate platforms... and .Net 5 will be effectively Standard 3.0 with code
from Core, Mono, etc as a single, unified framework.

The are deprecating all of the past in favor of .Net 5

~~~
1000010110
I don't think they would deprecate Framework yet. A lot of application rely on
it. I think they would support it less (see OWIN implementations), but
Framework still feels very active.

------
throwaway55554
I'm curious and don't see anything. But what about things like IPC? Is WCF
available yet? Is there an abstraction for namedpipes for all the platforms?

~~~
runfaster2000
IPC is already supported. We have no plans to support WCF (as a server) on
.NET Core.

~~~
mikequinlan
What components of.NET Framework 4.8 will not be supported on the Windows
version of.NET 5?

------
catchmeifyoucan
Is this pretty much like how Java is today?

~~~
max76
Java is a programming language that can target many different run times.

------
mehrdadn
Semi-tangent, but as someone who didn't try to follow AOT compilation but very
much wants to, would anyone have tl;dr instructions using the current version
of .NET on how to turn a HelloWorld.cs file into a native HelloWorld.exe?
You'd think it's just calling a couple of commands on the command line, but
every time I've searched for it I've come across pages and pages of
documentation I had no time to look through.

~~~
1000010110
1\. Get Visual Studio. 2\. Install .NET. 3\. New > Create New Project. 4\.
Choose Console Application (C#). 5\. Rename Program to HelloWorld. 6\. Go to
properties and change Startup object to "ProjectName".HelloWorld. 7\. Run

~~~
mehrdadn
That just gives me a .NET EXE, not a native EXE. Also I was looking for
compilation instructions I can run myself (like csc HelloWorld.cs), not an IDE
to run everything for me.

------
userSumo
what kind of license would it have? i suppose MIT like .NET Core?

~~~
runfaster2000
The post clarifies that everything will be open source. We use a combination
of MIT and Apache 2. MIT is our default license for new code.

------
basetop
Is it just me, or are all critical comments being downvoted here. It seems
like this thread is overrun by PR folks and microsoft employees.

In the techcrunch windows terminal thread, one of the top comments starts with
"I've been developing on both MacBook Pro's and Windows laptops for 15+ years
now, on a daily basis, and I can confidently say that Windows laptops are
superior to MacBook Pro's for development in every way.".

It reads like an infomercial. What is going on? Did the "hacker" community
suddenly fall in love with Microsoft?

Another gem: "Satya seems to be the rare visionary CEO of a megacorp, instead
of just defaulting to a defensive and reactionary stance like most other
leaders."

~~~
michannne
I see many for and against points towards Microsoft. I don't pay attention to
Satya comments but I feel the same can be said for those as well. More
importantly, why do you believe the opinion of the dev community towards
Microsoft should be swayed one way or another?

If they do a good job at supporting development on all platforms, and their
intentions are clear and any intrusive additions can be spotted and built out
effectively, why should they not be commended for it?

------
Yuioup
.

~~~
oblio
.NET Core 3 will come with compatibility packs.

~~~
scarface74
For Windows only....

~~~
foepys
.NET Framework is only available on Windows, so I don't get your point.

~~~
scarface74
It was for clarification that while .Net Core/.Net 5 are cross platform,
“porting” Windows Forms doesn’t mean it will be cross platform.

------
kgwxd
Will it support Windows 9?

------
Wow2019
They took years to rewrite C# compiler and delivery became _slower_?

------
ameyv
Looks like MS realized they made a mess with .net core ...before thinking
through how they should have done this... It was really not difficult to see
..if they wanted to make .net open source and their BA, PM and developer
should have seen this coming... after MS bought Xamarin..they could have
worked on mono and make things easier for everybody... Now they are abandoning
again this new '.Core' bandwagon...so much money and time was spend by
community on creating and building libraries product...

I just convinced my PM and team, that we should consider .net core and they
have agreed...we have started development of our new app..

This news will make things more complicated...Sigh

Edit: Quite negative votes..No need to down vote..just explain your viewpoint
with more civilized means using "reply"

~~~
UglyToad
Unless I misunderstood the article is it not the case that this is just .NET
Core 5 (we're currently on/near .NET Core 3)?

This announcement sounded more like unifying the various different bits of.
NET on 5 in future rather than yet another breaking change?

~~~
runfaster2000
It is both things ... basically .NET Core 5 (as you say) but also making it so
that .NET Core can support all modern .NET scenarios.

