
Announcing .NET Core 1.1 Preview 1 - wmccullough
https://blogs.msdn.microsoft.com/dotnet/2016/10/25/announcing-net-core-1-1-preview-1/
======
oblio
It's good that they're iterating rapidly.

> .NET Standard 1.6.1-preview1 was published as part of this release. .NET
> Standard 2.0 support is still coming.

I feel like the highlight of .NET Core will be when it finally implements .NET
Standard 2.0. For those who haven't been following, .NET Standard 2.0 is
basically the moment when .NET finally reaches cross platform consistency
parity with Java.

For Java, if you want to have a cross platform app, you just target Java. For
.NET versions pre-.NET Standard 2.0 you basically target a mishmash of
platforms through "profiles". Imagine that when you're creating a Java app
you'd be forced to chose a "profile" that says: this app supports JavaCombo12
(AIX, Solaris, Linux). Then once MacOS is available as a platform you have to
choose JavaCombo13, that includes that. And then JavaCombo14, JavaCombo15,
etc.

Oh, I almost forgot! To make things more interesting, each "combo" could have
different APIs available! :)

~~~
pjmlp
> Imagine that when you're creating a Java app you'd be forced to chose a
> "profile" that says

They are called:

\- Android Java

\- Java Micro Edition

\- Java Embedded Edition with (compact profile 1, 2 and 3)

\- Java Standard Edition

\- Java Enterprise Edition

\- MicroEJ Java

\- Real Time Java

Ah, then there are the vendor specific features like AOT compilation to native
code or value objects like the Packet Objects in J9, just to give a possible
example.

~~~
oblio
I thought someone would nitpick that statement. Microsoft supposedly designed
and built .NET as a cross platform framework, even though they only released
it for Windows. Yet many years after .NET's release and the .NET Core
announcement, they're still struggling to achieve parity with Java.

Meanwhile, many of the examples from your list don't compare 1:1 with .NET
profiles, because... :

\- Android Java

This was caused by Google, so not $VENDOR's fault (Sun/Oracle).

\- Java Micro Edition

This is moribund these days.

\- Java Embedded Edition with (compact profile 1, 2 and 3)

This targets a totally different use case than the average .NET profile (most
.NET profiles are minor variations on a theme).

\- Java Standard Edition

Let's just call this "Java" :)

\- Java Enterprise Edition

Let's call this "Java" \+ libs. It's hardly a profile, it's just Java + stuff
on top.

\- MicroEJ Java

I don't really know about this one.

\- Real Time Java

See my comment about Java Embedded.

.NET profiles are IMO, just an ugly hack to re-add portability to a platform
that was designed with portability in mind but then lost it gradually as it
became more and more integrated with Microsoft platforms.

~~~
pjmlp
> \- MicroEJ Java > I don't really know about this one.

A Java version produced by IS2T for micro-controllers, think cortex-M class.

[http://www.microej.com/](http://www.microej.com/)

[http://www.stm32j.com/products/](http://www.stm32j.com/products/)

As for the rest, we will have to agree to disagree. Regardless how it looks
like in detail, in the daily work they are issues to take into account when
trying to write portable Java code.

.NET was designed with portability across processors and Windows versions, not
for other vendors. Even Rotor wasn't fully compliant with .NET 1.0.

When looking at the histories told by Don Syme related to the initial generics
design and Ext-VOS, .NET genesis was to be a native platform based on COM.
Actually something that was brought back to life as .NET Native + WinRT.

As for the .NET profiles, they aren't perfect, but as someone that works daily
with Java and .NET, I look forward to them.

------
GordonS
I find all the terminology and tooling around .NET Core... confusing.

Let's say I want to target RHEL and CentOS, versions 5-7. If I build mono on a
machine with an old enough glibc, that single build will run on all of these.
What's the equivalent to run on all these platforms with .NET Core?

~~~
nightski
.NET Core is the equivalent to mono. However the .NET Core libraries were a
bit painful to port to since they were limited. So they are expanding this
with .NET Standard - which is an API specification - which you can use and
work across all .NET platforms (.NET Framework, .NET Core, or Xamarin).

Keep in mind it sounds like .NET Standard basically is between the full .NET
Framework and .NET Core. So if you have an existing .NET Framework app it's
very possible it would just work on .NET Standard.

~~~
GordonS
But what about runtimes? Can I have a single .NET runtime that will work with
all of those Linux versions? With mono I have a single runtime that actually
works across almost _every_ Linux distro. Can I do this with .NET, have a
generic runtime build that just works on everything?

~~~
Tsarbomb
From what I've seen, the answer is yes. Build once, drop and run anywhere.

~~~
GordonS
Any information on how? I've been trying from a while, but keep getting bogged
down in all the new terminology and constant changes to .NET Core...

~~~
nightski
.Net Core is the runtime. It's the cross platform version of the .NET
Framework.

.Net Standard is just an API specification which will be implemented on the
.NET Framework, .NET Core, or Xamarin runtimes. Technically it's a subset of
the .NET Framework libraries. It's more of an improvement on .NET Core as it
is bringing more APIs to that runtime.

So basically as long as you use the APIs in .NET Standard, your application
can be compiled for any of those 3 runtimes.

------
wmccullough
Bug fixes this release: [https://github.com/dotnet/core/blob/master/release-
notes/1.1...](https://github.com/dotnet/core/blob/master/release-
notes/1.1/1.1-preview1-commits.md)

>1380 APIs were added in this release

>Added support for Linux Mint 18, OpenSUSE 42.1, macOS 10.12, Windows Server
2016

------
krat0sprakhar
Question to the seasoned .NET devs - If you're planning to build a F# app that
will eventually be deployed on Linux and developed on a Mac, what (& why)
would be your choice - Mono or .NET Core?

~~~
redboxcandy
My plan is to target .NET Core. I like the idea of being able to run on cheap
Linux instances. Although Xamarin is part of Microsoft, I'm concerned Mono
might end up being the red-headed stepchild, with Core getting better company
backing. The only thing that sucks is that currently some of the larger cool
projects (like Suave and Akka.net aren't ready for Core yet (I think)). So
eventually: sweet, short-term might be a couple more headaches.

~~~
krat0sprakhar
I agree! In the new scheme of things I'm not sure how Mono fits into the .NET
landscape. I was eagerly waiting to get a answer in Changelog's latest
episode[0] but sadly they didn't cover this at all.

It's even more confusing that there is absolutely no mention of .NET Core on
the language's Github page -
[http://fsharp.github.io/](http://fsharp.github.io/)

[0] - [https://changelog.com/podcast/224](https://changelog.com/podcast/224)

------
bopcrane
Despite the uncertainties I have about .NET's future, I'm very excited for the
possibilities this will open up if they would continue this pace and just
listen to the community. I myself can't wait for the freedom to choose a linux
or windows server to deploy on

------
tmzt
Can anybody comment on what would be required to run .net 4.6 applications
using System.Web on this? Could the Mono codebase be used for this?

------
euroclydon
ASPNET Core 1.0 has dependency injection built in. Is there something similar
for non-aspnet core apps?

~~~
Sacho
There's a lot of popular nuget packages handling dependency injection, in
fact, the ASP.NET docs encourage you to use one in place of their own
rudimentary implementation.

The ones I'm aware of that have ported to .net core are StructureMap and
Autofac.

~~~
euroclydon
The more rudimentary the better if you ask me. DI should be a standard library
feature if you ask me.

------
nowprovision
Could be worse, can't see a new keyword yet

~~~
GordonS
_sigh_ , predictably, there are a few: LTS, FTS, train.

