Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 34 reacties
Bron: Microsoft, submitter: zeldalink

Microsoft heeft .NET Core 1.1 uitgegeven. Dit is een modulair platform voor webappliacties dat draait op Linux, macOS en Windows. Het maakt natuurlijk gebruik van .NET en je kan het vergelijken met Node.js of Go. Het geheel wordt onder een mix van MIT-, Apache 2- en CC BY 4.0-licenties uitgegeven. De aankondiging van deze versie ziet er als volgt uit:

Announcing .NET Core 1.1

We are excited to announce the release of .NET Core 1.1 RTM, the first “Current” release. You can start creating .NET Core 1.1 apps, today, in Visual Studio 2015, Visual Studio 2017 RC, Visual Studio Code and Visual Studio for the Mac.

We used the 1.1 release to achieve the following improvements:
  • .NET Core: Add distros and improve performance.
  • ASP.NET Core: Improve Kestrel, Azure support and productivity.
  • EF Core: Azure and SQL 2016 support.
You can see all the .NET Core changes in detail in the .NET Core 1.1 release notes. It’s a small delta on the .NET Core 1.1 Preview 1 release that we shipped 3 weeks ago.

Distributions

Support for the following distributions was added:
  • Linux Mint 18
  • OpenSUSE 42.1
  • macOS 10.12 (also added to .NET Core 1.0)
  • Windows Server 2016 (also added to .NET Core 1.0)
You can see the full list of supported distributions in the .NET Core 1.1 release notes.

Documentation

.NET Core documentation has been updated for the release and will continue to be updated. We are also in the process of making visual and content updates to the .NET Core docs to make the docs easier and more compelling to use.

The ASP.NET Core and Entity Framework, C# and VB docs were moved to docs.microsoft.com as part of this release. F# documentation was added a few months ago.

Documentation on docs.microsoft.com open source. You can help us make it better by filing issues and making contributions on GitHub. Best places to start are dotnet/docs and aspnet/docs.

Performance

We were recently informed by the fine folks at TechEmpower that ASP.NET Core 1.1 with Kestrel was ranked as the fastest mainstream fullstack web framework in the TechEmpower plaintext benchmark. That’s a great result, and the result of significant engineering effort.

We adopted a performance optimization for the CoreCLR runtime called Profile-Guided Optimization (PGO), for the .NET Core 1.1 Windows version. We’ve use this technique for the .NET Framework for many years, but had not yet used it for .NET Core. This improvement was not included in the earlier .NET Core 1.1 Preview 1 release.

PGO optimizes C++ compiler-generated binaries with information it records from apps it observes in our lab. We call this process “training”. It’s about as exciting as 6AM runs in the dark during the Winter. PGO records info about which codepaths are used in a binary and in what order. For this release, we used a simple “Hello World” app for training.

We saw a 15% improvement with the ASP.NET MusicStore app running with a PGO-optized CoreCLR in our lab and believe that these improvements will be representative to other Web applications. We hope to see greater improvements in the future as we increase the pool of apps we train with.

For Linux and macOS, we compile CoreCLR with Clang/LLVM. We intend to use the Clang version of PGO in the next release. Very preliminary scouting of Clang PGO suggests that we will see similar benefits.

APIs

There are 1380 new APIs in .NET Core 1.1. Many of the new APIs were added to support the product itself, include reading portable PDBs. .NET Core 1.1 supports .NET Standard 1.6.

.NET Standard 2.0 support is coming in an upcoming release (in 2017). It is not part of .NET Core 1.1.

Current Release

In the earlier .NET Core 1.1 blog post, I described that we have adopted the industry practice of differentiated releases, which we’ve called “Long-term Support (LTS)” and “Current”. .NET Core 1.1 is a Current release and also the first one. Once a given Current release has shipped, we expect very few updates, hopefully only security updates.

We recommend that most developers adopt LTS releases. It’s also the default experience we’ll include in Visual Studio. We do hope that some of you adopt Current releases to give us feedback, as well. It’s hard to quantify it, but we thinking an 80/20 split between LTS and Current across the entire .NET Core developer base would be about right.

Closing

Please try the new .NET Core release and give us feedback. There are a lot of key improvements across .NET Core 1.1, ASP.NET Core and EF Core that will make your apps better and faster. It’s the first Current release, providing you with feature faster, provided you are happy with updating .NET Core more quickly than the LTS multi-year supported releases.
Versienummer:1.1
Releasestatus:Final
Besturingssystemen:Windows 7, Linux, macOS, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10
Website:Microsoft
Download:https://www.microsoft.com/net/download/core
Licentietype:Voorwaarden (GNU/BSD/etc.)

Updategeschiedenis

Moderatie-faq Wijzig weergave

Reacties (34)

Huh? Vergelijkbaar met Node.js of Go?

Go is zo wie zo een geheel ander soort taal en omgeving, dus die vergelijking gaat niet op. En Node.js klopt in zekere zin wel, maar een betere vergelijking is natuurlijk Java / JRE.

Grote voordelen van .NET Core zijn:

+ multi platform
+ zeer snel (vergelijkbaar met Java)
+ open source
+ compacter / leaner

[Reactie gewijzigd door rkmuller op 29 november 2016 14:07]

Ten eerste is .net geen taal maar een platform. Als je het dan toch graag wil kan je c#.NET vergelijken met JAva maar .NET Core kan je beter vergelijken met Node of Go aangezien ze erg op elkaar lijken, cross platform zijn en alles met packagemanagers doen en alle tooling van uit de commandline werkt. Ik zou zeggen, probeer .NET Core eens.

Spring boot zou je dan wel weer met .NET Core kunnen vergelijken

[Reactie gewijzigd door GrooV op 29 november 2016 14:38]

Ik schrijf toch "java / jre"? De vergelijking met Go mag je uitleggen.
Ik ben inmiddels al weken met .NET Core bezig (niet professioneel) en Java / Go gebruik ik beroepsmatig. Ik denk dat ik de omgevingen wel begrijp :)

En spring boot met .NET Core ... nu ben ik helemaal de weg kwijt :)
Lees eerst eens mijn andere argumenten?

.NET Core is volledig anders dan de Java stack, voor .NET core maakt het niet uit welke CLR je installeerd, dit zijn namelijk allemaal NuGet packages, dit is volledig anders dan JRE/JVM/JDK waar je deze volledige op je machine moet hebben staan.

Je kan per applicatie kiezen welke runtime je draait, 1.0 en 1.1 naast elkaar.

Verder draait kan je .NET Core native draaien op windows en linux, wat niet mogelijk is met de JRE/JDK

Dat C# en Java en .NET en JRE op elkaar lijken wil niet zeggen dat .NET Core dat ook doet.

De vergelijking met Sprint boot gaat weer over het gebruik van Convention > Configuration en de eenvoud om een standalone applicatie op te tuigen. (Net zoals in .NET Core) Ook kan je spring-cli vergelijken met de dotnet tooling

[Reactie gewijzigd door GrooV op 29 november 2016 16:44]

Wat bedoel je met maakt niet uit met welke CLR je installeert? Het is wel handig dat je de juiste CLR installeert op je platform. Verschil met .Net Core is, is dat je de CLR mee kan publishen met je app, waardoor hij niet per de ge´nstalleerd te staan.

Verder wordt hier ASP.Net Core vaak in dezelfde adem genoemd met .Net Core. ASP.Net Core is een totale rewrite van ASP.Net en draait op .Net Core. Een kleinere BCL en draait op CoreCLR.

Ook is .Net Core zeer stabiel en ASP.Net Core ook. Wat nog wel eens wat instabiel is, is de tooling met .Net CLI.
En zeer snel in vergelijking tot php, als ik me niet vergis (met de php Roslyn compiler)

[Reactie gewijzigd door TheNymf op 29 november 2016 14:14]

+ zeer snel (vergelijkbaar met Java)
Java zeer snel?

C#, PHP, Perl, Python, JavaScript, ... geven geen goede performance. Die talen neem je ook niet voor performance.

Zie bijvoorbeeld http://roscidus.com/blog/...n-to-ocaml-retrospective/
Ben nu vooral bezig met traditionele ASP MVC projectjes. Denk dat ik het toch stilaan eens ga proberen. Na SQL op Linux uit testen, hier eens mee aan de slag gaan.

Heb altijd zo'n gevoel van "gaat dit wel goed gaan" maar ja, eigenlijk is er geen reden waarom het niet goed zou gaan
Updaten vanaf ASP.NET MVC gaat niet zo gemakkelijk.
Het basisprincipe is wel gelijk (controllers/views etc), maar de startup en de routing is nogal gewijzigd.

Het is meer van:
Nieuwe project maken
basis inrichten
controllers en views kopieren.
Dan dan...... net zolang knutselen tot het werkt.
Het is ook geen update. Je stapt van het full framework (4.5.x of 4.6.x) over naar core. Daarom hebben ze het geen asp.net 5 genoemd, omdat mensen het dan zien als een upgrade terwijl het een re-write is. Minder legacy en geen Winforms etc.
Maar voordat je de overstap wil maken moet je even kijken of je nuget pakketten beschikbaar zijn voor dotnet core https://icanhasdot.net/
Heb me misschien niet helemaal duidelijk uitgedrukt. Het is niet de bedoeling om bestaande projecten om te zetten maar om nieuwe projecten hiermee te maken.

Zeker met Entity framework zit waarschijnlijk alles er in dat een data-verwerkende toepassing moet hebben
Zeker doen. Maar kijk even of je Nuget packages compatible zijn:
https://icanhasdot.net/
ik vond de preview 2 met project.json erg relaxt werken in combinatie met vs code, maar ben nu ivm preview 3 (core 1.1) over op vs 2017 rc ivm tooling.
Werk nu een tijdje met .Net Core (1.0, en reeds ge-upgrade naar 1.1) na een tijd in Java 8 (met o.a. Spring 4, etc) gewerkt te hebben. De taal (C#) is best fijn, i.c.m. met Linq is het fijn om selecties uit lijsten te doen (of combinaties te maken). De tooling is redelijk standaard. Visual Studio biedt veel (al kon ik niet echt zonder Resharper, ik ben toch erg verwend met IntelliJ in de Java wereld).

Wel merkte ik op dat (zeker in het begin van .Net core) e.a. niet zo stabiel was. Dit is een stuk verbeterd. Toch crashed Visual Studio nog regelmatig bij mij (voornamelijk bij switchen van branch (git) en het restoren van je projecten (project.json, lock files, etc)).

Dat gezegd hebbende, het geheel zit best goed in elkaar. Redelijk rap en degelijk een API kunnen opbouwen met een frontend webapp (beiden in C#). Met allerlei 'standaard' MVC oplossingen die je in een fijne manier kunt opschrijven (in code).

Al met al zijn ze hard aan de weg aan het timmeren, erg tof!
Leuk! Zelfde ervaring hier. C# is natuurlijk klasse anders dan Java (moeilijk om het te omschrijven als beter, dat is zeer afhankelijk van de context) en MS is mijn inziens met dit project zeer goed bezig. VS Code is ook een zeer fraai product. Maar ja, stabiliteit van niet triviale apps is inderdaad minder dan ik gewend ben (Java / Go). Maar dat zal nog wel verbeteren.
Mag ik vragen wat je bedoelt met "triviale apps"? Ik heb al jaren geen Java meer geprogrammeerd (laatste keer was 2010 in eclipse). (Om even aan te geven dat mijn Java kennis outdated is en ik meer op de hoogte ben van C#)

[Reactie gewijzigd door capsoft op 29 november 2016 14:50]

Ja, dat mag je vragen. Zijn (delen van) libs die ik in de loop der tijd heb ontwikkeld (java) die ik nu **niet professioneel** (en als beginner in C#) probeer om te zetten / testen obv .NET Core / C#. Gewoon om betere "feeling" te krijgen met de taal. Specifieke toepassing waar ik op doelde: Data Quality analyse van (zeer grote > 2GB - 10 GB) bestanden, met name XML. Doel: ervaring opdoen en met name gevoel voor de omgeving te krijgen. Heb ik indertijd ook met Go gedaan en is een zeer effectieve manier geweest om deze taal onder de knie te krijgen. En in het geval van Go, een grote fan van te worden.
Ok bedankt, ik wist niet dat je dus zelf gemaakte applicaties bedoelde. 2gb - 10gb bestanden zijn flink. Ik lees zelf kleine XML files in. Dat gaat makkelijk. Ik kopieer eerst de XML en doe in Visual Studio "paste as classes" en dan kan ik met de nuget xmlserializer erbij halen en kun je dus makkelijk je input omzetten naar objecten van de vers gegenereerde classes :) Misschien is het interessant voor data quality analyse om het in Azure te gooien en met machine learning aan de slag te gaan of data lake.
Ik ben .net core onder de knie aan het krijgen door oude webforms code om te zetten naar mvc en dan direct .net core ipv full framework en loop hierbij soms tegen verschillen aan tussen full framework en core. Bijvoorbeeld crypto is in core anders. EntityFramework versie is anders etc.
Ja, Azure staat ook nog op de verlanglijst. Doe nu alles exclusief op AWS. Heb echter begrepen dat Azure ML erg interessant is voor auto classificatie.
Het leven is te kort voor zoveel mooie technologie :)
VS Code vond ik wat summier, maar ik ben dan ook verwend met IntelliJ/VS+Resharper achtige tooling.

Een van de 'nadelen' van .Net Core is dat je nog best wat moet uitzoeken soms, zo heb ik o.a. wat uitzoekwerk moeten doen om Integration Testing te kunnen doen. Na mijn onderzoekje heb ik e.a. in een blog gestopt: http://www.stefanhendriks...th-an-in-memory-database/
Om Visual Studio wat productiever te maken kan ik je Resharper aanraden. Van de makers van IntelliJ ;)
Inderdaad, dat gebruik ik ook. Nu is VS op zich al wel wat verbeterd maar ik kon toch niet zonder Resharper. Wel zonde want voor VS Professional betaal je ook al weer flink en dan ook nog eens een licentie op Resharper...

Aan de andere kant, goed gereedschap is niet goedkoop ;-)
Met betrekking tot het "niet zo stabiel", er is een verschil tussen of .NET Core stabiel is en of Visual Studio stabiel is. Ik geloof dat er nog een paar problemen zijn met de tools voor .NET Core in Visual Studio, maar echte problemen met .NET Core ken ik zelf niet.

C# is ook vanuit mijn standpunt voor beginners en professionals beide een plezier om mee te werken.

P.S.
LINQ is vergelijkbaar met de Java 8 Streams API!
Je hebt gelijk. Ik merk dat vooral VS bij mij niet stabiel is, vooral bij de restore processen.

Op de Mac heb ik vooral in het begin ook gezien dat .Net Core niet stabiel is, ook dit is gelukkig een stukje verbeterd, heb nu een tevreden collega die op een Mac werkt en het werkt best aardig.

Goeie toevoeging, het is idd LINQ wat ik bedoelde. T.o.v. de Java 8 streams API is het een verademing.
Vanaf versie 1.2 wordt het eigenlijk pas echt interessant.

Dan hebben we namelijk de .NET platform standard 2.0 en zullen meer en meer libraries het zowel op .NET core als op de Full CLR doen.

En hopelijk hebben we dan wel een goede graphics library.

Dus voor mij is het nog even wachten tot april 2017 ofzo.

In de tussentijd vermaak ik me overigens prima met NancyFX op de full CLR. Ook daarvan wordt een nieuwe versie gemaakt die straks op .NET core gaat werken :)
En hopelijk hebben we dan wel een goede graphics library.
Ik denk niet dat je ooit een graphics library als onderdeel van netcore gaat zien. Wel als externe library, eventueel van Microsoft zelf.
Het echte probleem zit hem in de hardware acceleratie.

De library zal op de achtergrond met iets anders gaan praten. Eventueel Google Skia. Er zal dan iets ervoor zorg moeten dragen dat deze dependency aanwezig is.

Door het onderdeel van de runtime en de standard API te maken weet je zeker dat het er altijd is.

Doe je dit niet, dan raak je het eenvoudige deployment scenario van .NET (Core) applicaties kwijt.
Ik snap het probleem niet helemaal. Netstandard zal nooit een enkele graphics library bevatten, die zijn inherent platform-gelimiteerd. Wat je wel zal zien zijn bindings voor OpenGL, Vulkan, en DirectX. Wat overigens exact hetzelfde is als het huidige scenario met .Net.
Het probleem is simpel: als je een api bouwt die plaatjes (bijv thumbnails) genereert, dan kun je hem niet xcopy deployen op een willekeurig systeem dat .Net ondersteunt.

Terwijl dat met het volledige framework en ook Mono gewoon wel kan.

Je werpt dus een beperking op.

Dat iets inherent platform gelimiteerd is, vind ik in dit geval flauwekul. Als Java het kan, zou .Net het ook moeten kunnen :)
Ik neem aan dat je VolatileImage bedoelt? Dat is een goede. Dat zou nog wel nuttig zijn, ik dacht dat je een uitgebreidere graphics API in gedachten had, ipv. een simpele variant op Graphics. Nee, dat is op zich wel mogelijk, voornamelijk omdat het nog bruikbaar is met een pure CPU implementatie.

Overigens voor het scenario thumbnails vermoed ik dat gewoon op de CPU werken een stuk vlotter is.
Dat .NET Core alleen voor webapplicaties is lijkt me wat krap door de bocht. Volgens mij is het meer een afgeslakte versie van .NET Framework. Volgens Wikipedia:
.NET Core supports four cross-platform scenarios: ASP.NET Core web apps, command-line apps, libraries, and Universal Windows Platform apps.
Het is .NET omgevormd tot een generiek platform. Het enige wat er eigenlijk uit is gehaald zijn de diep platform afhankelijke onderdelen.

Het is een kwestie van tijd voor daar bindings en libraries voor ontstaan, technisch gezien kan het al.
Een iets duidelijkere changelog dan die Microsoft standaard aanbiedt:
https://blogs.msdn.micros...nouncing-asp-net-core-1-1


Om te kunnen reageren moet je ingelogd zijn



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True