.NET Core 2.0 is available today as a final release. You can start developing with it at the command line, in your favorite text editor, in Visual Studio 2017 15.3, Visual Studio Code or Visual Studio for Mac. It is ready for production workloads, on your own hardware or your favorite cloud, like Microsoft Azure.
- Downloads
- Supported OSes
- Release Notes
- Known Issues
- Documentation
- Tutorials
- Samples
- Contributors
- Commits
We are also releasing ASP.NET Core 2.0 and Entity Framework Core 2.0. Read the ASP.NET Core 2.0 and the Entity Framework Core 2.0 announcements for details. You can also watch the launch video on Channel 9 to see many of the new features in action.
The .NET Standard 2.0 spec is complete, finalized at the same time as .NET Core 2.0. .NET Standard is a key effort to improve code sharing and to make the APIs available in each .NET implementation more consistent. .NET Standard 2.0 more than doubles that set of APIs that you have available for your projects.
.NET Core 2.0 has been deployed to Azure Web Apps. It is now available in all Azure regions.
.NET Core 2.0 includes major improvements that make .NET Core easier to use and much more capable as a platform. The following improvements are the biggest ones and others are described in the body of this post. Please share feedback and any issues you encounter at dotnet/core #812.
Runtime
- Major performance improvements in the runtime and framework
- Implements .NET Standard 2.0
- 6 new platforms supported, including Debian Stretch, SUSE Linux Enterprise Server 12 SP2, and macOS High Sierra.
- RyuJIT is the x86 JIT in .NET Core 2.0
- Linux and Windows ARM32 builds now available, in preview.
SDK
dotnet restore
is now an implicit command.- .NET Core and .NET Standard projects can reference .NET Framework NuGet packages and projects.
- The .NET Core SDK can be built from source with the source-build repo.
Visual Studio
- Live Unit Testing supports .NET Core
- Code navigation improvements
- C# Azure Functions support in the box
- CI/CD support for containers
For Visual Studio users: You need to update to the latest versions of Visual Studio to use .NET Core 2.0. You will need to install the .NET Core 2.0 SDK separately for this update.
Thanks!
On behalf of the entire team, I want to express our gratitude for all the direct contributions that we received for .NET Core 2.0. Thanks! Some of the most prolific contributors for .NET Core 2.0 are from companies investing in .NET Core, other than Microsoft. Thanks to Samsung and Qualcomm for your contributions to .NET Core.
The .NET Core team shipped two .NET Core 2.0 previews (preview 1 and preview 2) leading up to today’s release. Thanks to everyone who tried out those releases and gave us feedback.
Using .NET Core 2.0
You can get started with .NET Core 2.0 in just a few minutes, on Windows macOS or Linux.
You first need to install the .NET Core SDK 2.0.
You can create .NET Core 2.0 apps on the command line or in Visual Studio.
Creating new projects is easy. There are templates you can use in Visual Studio 2017. You can also create new application at the command line with dotnet new
, as you can see in the following example.
C:\samples>dotnet new console -o console-app
C:\samples>cd console-app
C:\samples\console-app>dotnet run
Hello World!
Upgrading Existing Applications
You can also upgrade an existing application to .NET Core 2.0. In Visual Studio, you can change the target framework of an application to .NET Core 2.0.
If you are working with Visual Studio Code or another text editor, you will need to update the target framework to netcoreapp2.0
.
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
You can read more in-depth instructions in the Migrating from ASP.NET Core 1.x to ASP.NET Core 2.0 document.
Upgrading Libraries
You do not need to update libraries to .NET Standard 2.0. .NET Standard 1.x versions will be supported forever and are not considered “old” or “stale”. .NET Standard is just a spec, so it doesn’t age in the way that platforms do. In general, libraries should target the lowest version of .NET Standard they can tolerate (for maximum .NET implementation applicability) unless they require APIs in higher versions. If you do want to update libraries, you can do it the same way, either in Visual Studio or directly in the project file, as you can see with the following project file segment that target .NET Standard 2.0.
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
You can also create libraries that target .NET Core. This is not recommended as a general scenario because .NET Core libraries can only be used by .NET Core applications. They cannot be used by .NET Framework of Xamarin applications, as .NET Standard libraries can (this is why .NET Standard is the recommended target framework for libraries). You should only build .NET Core libraries if you require APIs that are only in .NET Core.
Relationship to .NET Core 1.0 and 1.1 Apps
You can install .NET Core 2.0 on machines with .NET Core 1.0 and 1.1. Your 1.0 and 1.1 applications will continue to use the 1.0 and 1.1 runtimes, respectively. They will not roll forward to the 2.0 runtime unless you explicitly update your apps to do so.
By default, the latest SDK is always used. After installing the .NET Core 2.0 SDK, you will use it for all projects, including 1.0 and 1.1 projects. As stated above, 1.0 and 1.1 projects will still use the 1.0 and 1.1 runtimes, respectively.
You can configure a directory (all the way up to a whole drive) to use a specific SDK by creating a global.json file that specifies a specific .NET Core SDK version. All dotnet
uses “under” that file will use that version of the SDK. If you do that, make sure you have that version installed.
.NET Core Runtime Improvements
The .NET Core 2.0 Runtime has the following improvements.
Performance Improvements
There are many performance improvements in .NET Core 2.0. The team published a few posts describing the improvements to the .NET Core Runtime in detail.
- Performance Improvements in .NET Core
- Performance Improvements in RyuJIT in .NET Core and .NET Framework
- Profile-guided optimization in .NET Core 2.0
.NET Core 2.0 Implements .NET Standard 2.0
The .NET Standard 2.0 spec has been finalized at the same time as .NET Core 2.0.
We have more than doubled the set of available APIs in .NET Standard from 13k in .NET Standard 1.6 to 32k in .NET Standard 2.0. Most of the added APIs are .NET Framework APIs. These additions make it much easier to port existing code to .NET Standard, and, by extension, to any .NET implementation of .NET Standard, such as .NET Core 2.0 and the upcoming version of Universal Windows Platform (UWP).
.NET Core 2.0 implements the .NET Standard 2.0 spec: all 32k APIs that the spec defines.
You can see a diff between .NET Core 2.0 and .NET Standard 2.0 to understand the set of APIs that .NET Core 2.0 provides beyond the set required by the .NET Standard 2.0 spec.
Much easier to target Linux as a single operating system
.NET Core 2.0 treats Linux as a single operating system. There is now a single Linux build (per chip architecture) that works on all Linux distros that we’ve tested. Our support so far is specific to glibc-based distros and more specifically Debian- and Red Hat-based Linux distros.
There are other Linux distros that we would like to support, like those that use musl C Standard library, such as Alpine. Alpine will be supported in a later release.
Please tell us if the .NET Core 2.0 Linux build doesn’t work well on your favorite Linux distro.
Similar improvements have been made for Windows and macOS. You can now publish for the following “runtimes”.
linux-x64
,linux-arm
win-x64
,win-x86
osx-x64
Linux and Windows ARM32 builds now available, in Preview
The .NET Core team is now producing ARM32 builds for .NET Core 2.0+. These builds are great for using on Raspberry Pi. These builds are not yet supported by Microsoft and have preview status.
The team is producing Runtime and not SDK builds for .NET Core. As a result, you need to build your applications on another operating system and then copy to a Raspberry Pi (or similar device) to run.
There are two good sources of .NET Core ARM32 samples that you can use to get started:
Globalization Invariant Mode
.NET Core 2.0 includes a new opt-in globalization mode that provides basic globalization-related functionality that is uniform across operating systems and languages. The benefit of this new mode is its uniformity, distribution size, and the absence of any globalization dependencies.
See .NET Core Globalization Invariant Mode to learn more about this feature, and decide whether the new mode is a good choice for your app or if it breaks its functionality.
.NET Core SDK Improvements
The .NET Core SDK 2.0 has the following improvements.
dotnet restore is implicit for commands that require it
The dotnet restore
command has been a required set of keystrokes with .NET Core to date. The command installs required project dependencies and some other tasks. It’s easy to forget to type it and the error messages that tell you that you need to type it are not always helpful. It is now implicitly called on your behalf for commands like run
, build
and publish
.
The following example workflow demonstates the absense of a required dotnet restore
command:
C:\Users\rich>dotnet new mvc -o mvcapp
The template "ASP.NET Core Web App (Model-View-Controller)" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/template-3pn for details.
Processing post-creation actions...
Running 'dotnet restore' on mvcapp\mvcapp.csproj...
Restoring packages for C:\Users\rich\mvcapp\mvcapp.csproj...
Restore completed in 32.3 ms for C:\Users\rich\mvcapp\mvcapp.csproj.
Generating MSBuild file C:\Users\rich\mvcapp\obj\mvcapp.csproj.nuget.g.props.
Generating MSBuild file C:\Users\rich\mvcapp\obj\mvcapp.csproj.nuget.g.targets.
Restore completed in 2.26 sec for C:\Users\rich\mvcapp\mvcapp.csproj.
Restore succeeded.
C:\Users\rich>cd mvcapp
C:\Users\rich\mvcapp>dotnet run
Hosting environment: Production
Content root path: C:\Users\rich\mvcapp
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
Application is shutting down...
Reference .NET Framework libraries from .NET Standard
You can now reference .NET Framework libraries from .NET Standard libraries using Visual Studio 2017 15.3. This feature helps you migrate .NET Framework code to .NET Standard or .NET Core over time (start with binaries and then move to source). It is also useful in the case that the source code is no longer accessible or is lost for a .NET Framework library, enabling it to be still be used in new scenarios.
We expect that this feature will be used most commonly from .NET Standard libraries. It also works for .NET Core apps and libraries. They can depend on .NET Framework libraries, too.
The supported scenario is referencing a .NET Framework library that happens to only use types within the .NET Standard API set. Also, it is only supported for libraries that target .NET Framework 4.6.1 or earlier (even .NET Framework 1.0 is fine). If the .NET Framework library you reference relies on WPF, the library will not work (or at least not in all cases). You can use libraries that depend on additional APIs,but not for the codepaths you use. In that case, you will need to invest singificantly in testing.
You can see this feature in use in the following images.
The call stack for this app makes the dependency from .NET Core to .NET Standard to .NET Framework more obvious.
.NET Standard NuGet Packages no longer have required dependencies
.NET Standard NuGet packages no longer have any required dependencies if they target .NET Standard 2.0 or later. The .NET Standard dependency is now provided by the .NET Core SDK. It isn’t necessary as a NuGet artifact.
The following is an example nuspec (recipe for a NuGet package) targeting .NET Standard 2.0.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>ClassLibrary1</id>
<version>1.0.0</version>
<authors>ClassLibrary1</authors>
<owners>ClassLibrary1</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package Description</description>
<dependencies>
<group targetFramework=".NETStandard2.0" />
</dependencies>
</metadata>
</package>
The following is an example nuspec (recipe for a NuGet package) targeting .NET Standard 1.4.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>ClassLibrary1</id>
<version>1.0.0</version>
<authors>ClassLibrary1</authors>
<owners>ClassLibrary1</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package Description</description>
<dependencies>
<group targetFramework=".NETStandard1.4">
<dependency id="NETStandard.Library" version="1.6.1" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Visual Studio 2017 version 15.3 updates
Side-by-Side SDKs
Visual Studio now has the ability to recognize the install of an updated .NET Core SDK and light up corresponding tooling within Visual Studio. With 15.3, Visual Studio now provides side-by-side support for .NET Core SDKs and defaults to utilizing the highest version installed in the machine when creating new projects while giving you the flexibility to specify and use older versions if needed, via the use of global.json file. Thus, a single version of Visual Studio can now build projects that target different versions of .NET Core.
Support for Visual Basic
In addition to supporting C# and F#, 15.3 now also supports using Visual Basic to develop .NET Core apps. Our aim with Visual Basic this release was to enable .NET Standard 2.0 class libraries. This means Visual Basic only offers templates for class libraries and console apps at this time, while C# and F# also include templates for ASP.NET Core 2.0 apps. Keep an eye on this blog for updates.
Live Unit Testing Support
Live Unit Testing (LUT) is a new feature we introduced in Visual Studio 2017 enterprise edition and with 15.3 it now supports .NET Core. Users who are passionate with Test Driven Development (TDD) will certainly love this new addition. Starting LUT is as simple as turning it ON from the menu bar: Test->Live Unit Testing->Start.
When you enable LUT, you will get unit test coverage and pass/fail feedback live in the code editor as you type. Notice the green ticks and red x’s shown in the code editor in image below.
IDE Productivity enhancements
Visual Studio 2017 15.3 has several productivity enhancements to help you write better code faster. We now support .NET naming conventions and formatting rules in EditorConfig allowing your team to enforce and configure almost any coding convention for your codebase.
With regards to navigation improvements, we’ve added support for camelCase matching in GoToAll (Ctrl+T), so that you can navigate to any file/type/member/symbol declaration just by typing cases (e.g., “bh” for “BusHelpers.cs”). You’ll also notice suggested variable names (Fig.2) as you are typing (which will adhere to any code style configured in your team’s EditorConfig).
We’ve added a handful of new refactorings including:
- Resolve merge conflict
- Add parameter (from callsite)
- Generate overrides
- Add named argument
- Add null-check for parameters
- Insert digit-separators into literals
- Change base for numeric literals (e.g., hex to binary)
- Convert if-to-switch
- Remove unused variable
Project System simplifications
We further simplified the .csproj project file by removing some unnecessary elements that were confusing to users and wherever possible we now derive them implicitly. Simplification trickles down to Solution Explorer view as well. Nodes in Solution Explorer are now neatly organized into categories within the Dependencies node, like NuGet, project-to-project references, SDK, etc.
Another enhancement made to the .NET Core project system is that it is now more efficient when it comes to builds. If nothing changed and the project appears to be up to date since the last build, then it won’t waste build cycles.
Docker
Several important improvements were made to .NET Core support for Docker during the 2.0 project.
- Docker latest tag moved to .NET Core 2.0
- microsoft/dotnet Docker Hub README adopted segmented OS/Arch style
- Linux ARM32 Docker images are now available.
- .NET Core 2.0 multi-arch tags now use Debian Stretch
- .NET Core Docker images use multi-arch based tags
- .NET Core supports Multi-Stage Build
Support and Lifecycle
.NET Core 2.0 is a new release, supported by Microsoft . You can start using it immediately for development and production.
Microsoft has two support levels: Long Term Support (LTS) and Current release. LTS releases have three years of support and Current releases are shorter, typically around a year, but potentially shorter. .NET Core 1.0 and 1.1 are LTS releases. You can read more about these support levels in the .NET Support and Versioning post. In that post, “Current” releases are referred to as “Fast Track Support”.
.NET Core 2.0 is a Current release. We are waiting to get your feedback on quality and reliability before switching to LTS support. In general, we want to make sure that LTS releases are at the stage where we only need to provide security fixes for them. Once you deploy an app with an LTS release, you shouldn’t have to update it much, at least not due to platform updates.
.NET Core 1.1
.NET Core 1.1 has transitioned to LTS Support, adopting the same LTS timeframe as .NET Core 1.0.
.NET Core 1.0 and 1.1 will both go out of support on June 27, 2019 or 12 months after the .NET Core 2.0 LTS release, whichever is shorter.
We recommend that all 1.0 customers move to 1.1, if not to 2.0. .NET Core 1.1 has important usability fixes in it that make for a significantly better development experience than 1.0.
Red Hat
Red Hat also provides full support for .NET Core on RHEL and will be providing a distribution of .NET Core 2.0 very soon. We’re excited to see our partners like Red Hat follow our release so quickly. For more information head to RedHatLoves.NET.
Closing
We’re very excited on this significant milestone for .NET Core. Not only is the 2.0 release our fastest version of .NET ever, the .NET Standard 2.0 delivers on the promise of .NET everywhere. In conjunction with the Visual Studio family, .NET Core provides the most productive development platform for developers using MacOS or Linux as well as Windows. We encourage you to download the latest .NET Core SDK from https://dot.net/core and start working with this new version of .NET Core.
Please share feedback and any issues you encounter at dotnet/core #812.
Watch the launch video for .NET Core 2.0 to see this new release in action.
> We have more than doubled the set of available APIs in .NET Standard from 13k in .NET Standard 1.6 to 32k in .NET Standard 2.0.
… do you even math, bro?
Oops. Just looked at the numbers again. Looks like I fail at math this morning. 🙁
+20K more then APIs than .NET Standard 1.x
About 70% of NuGet packages are API compatible.
The images in this post are not loading for me. Since they link to https://github.com/Microsoft/dotnet-blog/ and that repo is 404, is that repo private by accident?
Oops. Fixed. Thanks for reporting.
We use GitHub for blog drafts, too!
How about AspNetCore.SignalR ?
Q4 2017 (2.1) https://github.com/aspnet/Home/wiki/Roadmap
The migration guide link is incorrect. Should be https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/
Fixed. Thanks. I mis-copied it.
Wrong link for Migrating from ASP.NET Core 1.x to ASP.NET Core 2.0 -> https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/
Fixed. Thanks.
Amazing work, and congrats to the team. I started using .Net Core 1.1 around two months ago for daily Web/API development and haven’t looked back since. The platform and tooling are superb, not to mention the small but much appreciated language updates in C# 7.0.
It’s hard to go back to using Unity when I’m doing client work. At least 2017.1 brings us .Net 4.6/C# 6.0.
Web development is actually fun again. Keep up the good work!
Great news. Perfect timing for my new project 🙂
Would it be possible to publish the SDK installer to Chocolatey?
We have been thinking about doing two things:
– Publish the SDK to Chocolatey.
– Publish the SDK to Homebrew.
Whomever wants those, please create an issue at the dotnet/core repo. Whichever one has the most feedback, we’ll do first.
I created the Chocolatey issue here:
https://github.com/dotnet/core/issues/829
I am impressed. Great news! Net Core is great idea in and I believe .Net Core 2.0 will make it practically useful and on par with development experience which we had in full framework, now with so many opportunities. Thanks for making it happen.
I’m so happy my VB.NET stuff works! The whole toolchain works exactly as described, binaries are performant… everything, really, is as I’d hope it could be!
RedHat only name RHEL7 on the RedHatLoves.NET site you linked. Do you know if RHEL6 is likely to be supported? Most machines I use daily are going to be stuck on RHEL6 until it’s EOL’d in 2020.
We are working on that and are close to releasing RHEL 6 support. We have gotten this request from multiple customers.
*hops up and down with excitement*
I realise what a silly thing it is to ask for timelines, sometimes, but when you say “close”, do you mean “this calendar year”? That would align with some other efforts I have progressing at the moment.
Yes. Likely quite soon. You won’t have to wait for someone to come down your chimney in a red suit.
Mail me if you (or anyone else) want to be on our early access list for RHEL6 at rlander@ms.
When is a fully functional code coverage coming? We were hoping it’d be .Net Core 2.0
We are about to invest more in unit testing / code coverage. My understanding is that some scenarios work and are just poorly documented. I’ll ping folks to get them to look at code coverage in particular. Feel free to mail me at rlander@ms if you want to be first of the list to get that info.
Thanks. More on that is that code coverage with dotnet test (without visual studio) doesn’t work, and only can be done through Visual Studio. It requires us to manually check code coverage during code review and prevents us from getting code coverage from command line and publish it to TFS, which we use for reports, rejection of patches, etc.
When will WPF.Core be announced? Supporting WebAssembly+WebGL compilation ideally.
No current plans on that. We have been experimenting with web assembly recently but don’t have anything to report right now.
Hey Guys,
Congratulations on the release!
The following page needs to be updated to reflect the out of preview status: https://www.microsoft.com/net/targeting?utm_source=getdotnetsdk&utm_medium=referral
I noticed that .NET Core 2.0 isn’t included with the VS2017 update, is that going to be added in the future so .NET Core 2.0 projects are a selectable option without an additional install?
Will update that page. It got missed today. Thanks for reporting.
.NET Core 2.0 will be part of the Visual Studio installation soon, as soon as Visual Studio 2017 15.4 or 15.5. Part of the plan.
Rich,
I installed VS2017 15.3 update and then downloaded and installed .NET Core 2.0 SDK (both x64 and x86). I restarted my machine and opened VS 2017 to create a new ASP.NET Core 2.0 website, however, VS 2017 only allows me to select .NET Core 1.0 or 1.1 BUT not v2.0 even I installed the SDK! VS states something like “A new .NET Core 2.0 is available to install” in that same dialog BUT I already have it installed! What could be the problem? Thanks,
That sounds odd to me. Can you double check in VS that you are using 15.3? Sometimes people have more than one version of Visual Studio 2017 installed. This has happened to me.
Thanks for the quick response Rich! Yes, it sounds odd to me too… The about dialog from my VS 2017 Community states Version 15.3.2 and the following screenshot is what I see when trying to create an ASP.NET Core website https://s29.postimg.org/7kzjdajon/vs2017.png
The links in your downloads are backwards for the windows binary downloads, but the installer links are correct.
Great news to see .NET 2.0 released currently installing right now. I have been looking forward to this for a year now.
Thanks DaFlame. I think I found the backward links and have fixed them.
Glad I can get off the daily binaries now and worry less about VS / runtime / sdk / 3rd party lib syncing issues.
I think 2.0 is finally the beginning of a new era of dotnet development, like 2.0 of the full framework.
Thanks for all the hard work.
Oh, you are the one who has been downloading our daily builds! Joke. Thanks for playing along as part of the release. I can imagine that you are happy to get on stable builds, for sure. Please do install a few .NET Core 2.1 builds after the development team comes back from “post 2.0 vacation”!
Congratulations! This is a most impressive release and significantly raises the bar for .Net Core.
Now that 2.0 is final, could you please share plans for upcoming versions?
I am most hopeful for a solid GUI solution, ideally WPF.
Server-side web and console applications are now covered well, but there is unfortunately little support for regular GUI applications.
Most of my customers require some form of (non-browser) GUI, which makes it difficult to go with complete .Net Core solution.
(I’m not interested in Xamarin. It is quite inferior to WPF in nearly all ways.)
Thanks much. I hope that we can raise the bar again with future releases. This one was indeed a big one.
We don’t have anything to share yet on GUI apps. There are a lot of GUI solutions available, particularly from the Mono ecosystem. Those have all been waiting to be ported to .NET Core, waiting for the 2.0-based API surface area. At the very least, I suspect that we’ll see a number of community-based solutions show up. I suspect you want a Microsoft-provided one. It may seem like we’ve got everything in good shape with 2.0 but we have a significant set of fundamentals features left to build before we get into the GUI space. On that note, I’ll post the .NET Core 2.1 roadmap doc soon.
I also want GUI solution from microsoft with good drag&drop designer like winforms/wpf. easy to use, cross-platform and web (webassembly). Hope you can focus on GUI soon and surprise us with something great.
Without a GUI we will not look at .NET Core.
We can’t deliver applications that need 2 frameworks to run.
No GUI = No .NET Core
Hi
Congratulations for such a nice release.
Just wanted to know will the installed 2.0 Preview version will it cause any issue? or can i uninstall it?
You can uninstall pre-release versions, but it doesn’t matter much. It is perfectly safe to leave them there. Most of the people of the .NET Core team don’t bother deleting old versions. They just take up disk space and not used.
What about TFS? I updated Restore and Build to 2.* but get errors like Multiple assemblies with equivalent identity have been imported
I have seen this when I wasn’t on the final version. If you are seeing this on the final version, please mail me at rlander@ms and we’ll figure out what is going on.
How can I get 2.* but not (preview)? I have only 2.* preview; 1.*; 0.*
I sent email but not response.
I tried .NET Core Tool Installer (Preview) but the same result.
Solution can be perfectly built localy.
I just responded. Thanks.
I was a bit wrong. Not TFS, but Team Services
Hi Rambalac,
Have you tried to add to add .NET Core Tool Installer (Preview) task on top of your build and
set “Version” to 2.0.0 and “Package to install” to SDK
we had some troubles with restore also, and this workaround help us
Just solved it. I did have .NET Core Tool Installer (Preview) task. But it should be install “SDK”, not just “Runtime”.
> With regards to navigation improvements, we’ve added support for camelCase matching in GoToAll (Ctrl+T), so that you can navigate to any file/type/member/symbol declaration just by typing cases (e.g., “bh” for “BusHelpers.cs”).
This is great! Something that’s been common in many other editors (Sublime Text, Rider, …). I just don’t understand why this only works in GoToAll and not in normal autocomplete as well. Would be very helpful!
@Matej, this has worked in auto-complete for a while in Visual Studio for C#, VB, TypeScript, and JavaScript. What is was called out here was added support in GoToAll
Is System.Random issue (https://connect.microsoft.com/VisualStudio/feedback/details/634761/system-random-serious-bug) fixed in this release?
Looking at source code, it doesn’t look like we did. I filed the following bug on your behalf. I’d appreciate if you could comment on what actual issues you run into with the current behavior.
Thanks, Immo. The issue is that in Mono System.Random implemented correctly, i.e. 51 and 31 are used. That’s why the .Net programs work differently. it could failed tests for example
“Reference .NET Framework libraries from .NET Standard” – Will this work for .NET core apps running on *nix? Or only on Windows? (I.e. we build an app in .NET Core 2.0, reference some old Nuget packages, and run it on Linux.)
If the API’s are covered by .NET Standard then older libraries will work on Windows, Mac and Linux.
In the LUT example, why is the method RegisterWorkout(…) marked with a red cross? It is called by 3 of the unit tests.
Hi Oren: I wrote the sample code for this and can share with you if you want. Shoot me an email at jomorris@microsoft.com. RegisterWorkOut() is exercised by 8 unit tests and one of the unit tests (TestTweetifyNoNotes()) is failing. Sample was written that way to demonstrate a unit test failure. If any one of the exercised unit test fails, then coverage icon is marked with a red cross. You can watch my video that explains Live Unit Testing feature at https://channel9.msdn.com/Events/Visual-Studio/Visual-Studio-2017-Launch/T105
Great work!
Hi Team,
Good work. working on stable version is more convincing than the preview-1, preview-2. I have some doubt though.
1) Few days back, I have created solution and was trying to understand Microsoft.AspnetCore.All 2.0.0-preview2-final. It has good implementation and breaking changes w.r.t. ConfigureServices(IServiceCollection services) and Configure(IApplicationBuilder app, IHostingEnvironment env) for Identity and Authentication implementation.
Team was suggesting to use services.AddCookingAuthentication() and other. and use app.UseAuthentication();
But when I have upgrade the version just few minutes back to stable 2.0, I got an error message. Is that something removed or not committed as a part of stable 2.0?
Take a look at the migration doc, that should include most of the changes you will need: https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/identity-2x
Hello! I’m so excited for .NET Core 2.0!
I am tackling an issue with JWT on .NET Core 2.0 that if anyone could help me out with an answer would be great.
https://stackoverflow.com/questions/45686477/jwt-on-net-core-2-0
What is the workload component ID for 2.0? I do not see it listed on the component directory. https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-enterprise
Thanks!
Matt
.NET Core 2.0 is not yet integrated into the Visual Studio Installer. We plan to do this in either Visual Studio 15.4 or 15.5.
In 15.3 the 2.0 SDK needs to be installed as a separate download https://www.microsoft.com/net/download/core which will then lightup 2.0 development in Visual Studio. It will be bundled into the Visual Studio installer in a future update.
Lots of nice things if we moved fully to .net core. But in the meantime please add some of these things to other project types.
For example, a Xamarin project I have doesn’t show the nice Project System layout simplifications that you show here even though I am using PackageReference style. Feels like that would be an easily transferred bit of functionality that would benefit many customers.
Can a framework 4.6.1 executable not include a core 2.0 library? Is only the other direction supported?
Error Project ‘C:\foo.csproj’ targets ‘.NETCoreApp,Version=v2.0’. It cannot be referenced by a project that targets ‘.NETFramework,Version=v4.6.1’.
Correct. Only one direction is support: core -> framework. This direction is supported as a kind of “likely to work opt-in experience” that is intended to ease transition to .NET Standard. It isn’t indicative of a new direction of “everything can reference everything”. If you have libraries that you want to work for multiple implementations, then you should build .NET Standard libraries. That’s exactly what they are for.
Thanks for the quick response!
So just to make sure I am parsing this correctly: “If you have libraries that you want to work for multiple implementations, then you should build .NET Standard libraries. That’s exactly what they are for.”
I read that as: “If I am creating a new library that I want to work on Windows, Linux, etc., .Net Standard 2.0 is the correct choice”. Is that accurate?
Not exactly. .NET Standard isn’t primarily about operating system breadth. It is about .NET implementation breadth, which happens only as a side-effect to give you operating system breadth. So, if you want a library to have applicability to .NET Framework, .NET Core and Xamarin, then .NET Standard is the right tool for the job. If you want a library to be solely used for .NET Core on Windows, macOS and Linux, then targeting .NET Core (netcoreapp) is fine. That said, we recommend you target .NET Standard if your library can fit within its API set because it gives you both .NET implementation and operating system applicability, which is a very nice characteristic.
“Nodes in Solution Explorer are now neatly organized into categories within the Dependencies node, like NuGet, project-to-project references, SDK, etc.” This is a great improvement over the current Projects organization. Can we expect (and when) a such organization for full .NET Framework projects (WPF, …)? Thanks.
Nice changes and I like that it is available in Azure already!!
Small question, when will it become available in VSTS, because I can’t use it their yet and because of that I can’t deploy to azure from VSTS.
I might do a manual deploy in the mean time but would be nice to see it working from VSTS!
The VSTS folks tell me that they now support .NET Core 2.0.
Great news about the release!
Any news on performance profiling support?
Thanks again
Launch of .NET Core 2.0 is reminiscent of when .NET Framework took off with release of .NET 2.0 in 2005…
What’s next for .NET Team @ Microsoft… .NET Native switch? LLVM?
Keep on rocking .NET !!!
GREAT WORK to everyone inside Microsoft and outside (in community) on making and growing .NET reach.
I was on the team in .NET Framework 2.0. Was my first .NET release, actually. It does feel similar. And of course, the prior release was 1.1 in both cases. I think .NET Framework 2.0 was actually a fair bit bigger (generics, X64, much much higher quality). When you add 2.0 and the next couple minor releases together, we’ll be there. More fun stuff coming!
> .NET Core 1.0 and 1.1 will both go out of support on June 27, 2019 or 12 months after the .NET Core 2.0 LTS release, whichever is shorter.
You mean “longer”, right? What is the point of LTS when you promised users it will be supported long term but releasing the next non-compatible version shortens it? That goes against the idea of LTS how I understand the term.
The text is correct. See the Microsoft Support statement here: https://github.com/dotnet/core/blob/master/microsoft-support.md.
The lifecycle is for free support. You can always call Microsoft Support for paid support after this period.
We do want developers to move forward to new versions. That’s why we created a lifecycle with variable length. We thought that 1 year was enough time to move forward to stay within free support. We discussed this with a number of customers who were happy with the plan.
We are working on making it easier to move forward to new .NET Core versions. It will get easier with each version. Your apps will get faster, scale better and be more secure.
Congrats on a big release!
Interesting change from 1.1 to 2.0. Not sure if I’m doing the wrong thing or the compiler is broken. I have a reflection-based method checking for certain method attributes during Web API testing:
public static bool VerifyHttpAttribute(Type controllerType, Type objectType, string methodName, Type attributeType)
{
// Get the method.
MethodInfo mi = controllerType.GetRuntimeMethod(methodName, new Type[] { objectType });
// Check for the correct attribute. Do not inspect attributes of any superclasses.
IEnumerable attribs = mi.GetCustomAttributes(false);
bool found = false;
foreach (Attribute attrib in attribs)
{
// We must find at least one instance of the right type.
if (attrib.GetType() == attributeType)
{
found = true;
break;
}
}
return found;
}
Pretty simple enumerator scanning the attributes, if any, and returning true if the “right” one was found. However, when targeting NET Core 2.0 (but not when targeting .NET Core 1.1), the wrong version of mi.GetCustomAttributes(false); is being selected. The version returning object[] is used, rather than the extension method returning IEnumerable. This results in a build error. Thoughts on what I should do about this? 😉
After updating to dotnet core 2.0 yesterday, the execution(dotnet run) process took long time than before. It’s just ‘hello world’ program and took around 2 seconds to execute it in command prompt. It was faster before.
I believe that the 2.0 CLI is slower. We will be working on fixing that.
The information regarding LTS support on this page ( that 1.1 has moved to LTS ) is contradicting the update here ( https://github.com/dotnet/core/blob/master/release-notes/download-archive.md) which still shows only 1.0 as the LTS version and both 1.1 and 2.0 listed under “Current”. Which one between these two sources needs to be taken as the baseline ? Please clarify
The page has been updated.
I have written a blog post for Core 2.0 Setup here: https://neelbhatt40.wordpress.com/2017/08/18/setup-for-asp-net-core-2-0/
Although I installed .net core 2 I cannot select it in VS 2017. How can I do this?
@Peter,
you need to install .NET Core 2.0 SDK and Visual Studio 2017 Update 3.
I did but it does not show
Are you planning to add .net core 2.0 support to Azure Web App On Linux ? This is quite important to lot of people…
Yes. This should already work. Can you try again?
Checked both the Azure portal and the documentation for Web Apps (https://docs.microsoft.com/en-us/azure/app-service/containers/app-service-linux-intro). There is no mention of .Net Core 2 on there, only 1.0-1.1.
Can you please provide a date for when you are planning to release it for Web Apps?
Does new VS invoke `dotnet restore` when creating a new project from UI? it’s a PITA scenario in 1.1
VS does something similar to `dotnet restore`. Yes, it is a pain for 1.1.
WIll take a look, thanks
Why can’t .NET Standard reference libraries from .NET Framework 4.7 and/or .NET Framework 4.6.2 ?
I just tried in Visual Studio 2017 15.3.2. It works. What version are you using?
This says it’s available in Azure, but I just deployed a test app to an Azure Web App, and the only available .NET Framework versions available are 4.7 and 3.5.
Unfortunately can’t build my previous web projects using microsoft net sdk web by any way. Can’t create new projects either.
https://stackoverflow.com/questions/45896671/cant-open-or-create-net-core-web-apps-after-vs-2k17-update
https://github.com/dotnet/cli/issues/6887
https://andrewlock.net/the-sdk-microsoft-net-sdk-web-specified-could-not-be-found/
Problem solved. Previous version of VS 2K17 saved projects in a directory other than the most recent. Just had to move old projets to new folder.
Great to see .NET Core – that ll be new era of coding. Waiting when it ll be included into VS2017
hi
I want to publish .net core 2.0 project for ubuntu16.04
after i build and pulish project and run it at ubuntu, i see this error :
Error: assembly specified in the dependencies manifest was not found ‘Microsoft.AspNetCore.ApplicationinSights’, version: ”, path: ‘lib/netstandard1.3/Microsoft.AspNetCore.ApplicationinSights.dll’
While I did not have this problem in .net core 1
please guide me…
tnx
Any update on when we can expect .Net Core 2.0 to transition to LTS?
Hi, I installed VS2017 15.3.5 and then installed .NET Core 2.0 SDK (x64) on Windows 10. After installations, I rebooted my computer and opened VS 2017. But VS 2017 only lists .NET Core 1.0 or 1.1. I don’t see 2.0 on the list. VS2017 indicates “A new .NET Core 2.0 is available to install”. I have tried many time to reinstall VS2017 and .NET Core 2.0. Both are most updated versions. Also, I tried to uninstalled some old programs which may be related with VS and frameworks. But the problem is still there. Please help.
Thanks,
Found out why. I have both .NET Core 1.0.0 (x86) and 1.0.0 (x64). I uninstalled the one with (x86) and keep one with (x64). Now I can see .NET Core 2.0 SDK
Is there any equivalent to the full set of properties that the TestContext class exposes in NetFx version of the MStest.TestFramework 1.2.1 package in the netstandard version? I only see a couple methods and properties on it, like WriteLine() and TestName.
Question: Can I use Net Core 2.0 on a Windows 2008 R2 Server?
thanks
Standard 2.0
6 new platforms supported, including Debian Stretch, SUSE Linux Enterprise Server 12 SP2, and macOS High Sierra.
RyuJIT is the x86 JIT in .NET Core 2.0
Linux and Windows ARM32 builds now available, in preview.
SDK
dotnet restore is now an implicit command.
.NET Core and .NET Standard projects can reference .NET Framework NuGet packages and projects.
The .NET Core SDK can be built fro
agario
agario unblocked thank you good post.