Announcing .NET Core 2.0 Preview 2
Today, we are announcing .NET Core 2.0 Preview 2. We have made improvements that we want to share and that we would love to get your feedback on. You can develop .NET Core 2.0 apps with Visual Studio 2017 Preview 15.3, Visual Studio for Mac or VS Code.
ASP.NET Core 2.0 Preview 2 is also releasing today and takes advantage of the improvements in .NET Core 2.0 and Visual Studio 2017.
You can download and get started with .NET Core 2.0 Preview 2 right now, on Windows, Linux and macOS:
- .NET Core 2.0 Preview 2
- .NET Core Docker Images
- ASP.NET Core 2.0 Preview 2
- Visual Studio 2017 Preview 15.3 for Windows
- Visual Studio for Mac
- Visual Studio Code
You can see complete details of the release in the .NET Core 2.0 Preview 2 release notes. Known issues and workarounds are included in the releases notes. Please read these if you are using Visual Studio for Mac or installing on Ubuntu. You can learn about previously released improvements in the .NET Core 2.0 Preview 1 blog post.
To everyone that helped with the release, thank you very much. We couldn’t have gotten to this spot without you and we’ll continue to need your help as we work together towards the final .NET Core 2.0 release.
The following platform support updates were made with .NET Core 2 Preview 2.
We have heard many requests for .NET Core 2.0 support with Azure App Service. .NET Core 2.0 Preview 2 is being rolled out to App Service currently and we expect it to be completed by the end of the week. Some data centers may already be available.
.NET Core 2.0 Docker multi-arch tags now use Debian Stretch instead of Debian Jessie. .NET Core 2.0 Debian Jessie tags will still be provided. Debian Stretch is considered by the .NET Core team to be a better default choice for .NET Core Docker Linux image users for the lifetime of .NET Core 2.x. There are no plans to update .NET Core 1.x in the same way.
.NET Core 2 Preview 2 has added support for SUSE Linux Enterprise Server (SLES). Our support starts with SLES 12 SP2. We would appreciate feedback on our SLES support. We’re also working with the folks at SUSE, so please do share with them that .NET Core support is important if that’s the case for you.
Key improvements are called out below.
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
The following example workflow demonstates the absense of a required
dotnet restore command:
C:Usersrich>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 mvcappmvcapp.csproj... Restoring packages for C:Usersrichmvcappmvcapp.csproj... Restore completed in 32.3 ms for C:Usersrichmvcappmvcapp.csproj. Generating MSBuild file C:Usersrichmvcappobjmvcapp.csproj.nuget.g.props. Generating MSBuild file C:Usersrichmvcappobjmvcapp.csproj.nuget.g.targets. Restore completed in 2.26 sec for C:Usersrichmvcappmvcapp.csproj. Restore succeeded. C:Usersrich>cd mvcapp C:Usersrichmvcapp>dotnet run Hosting environment: Production Content root path: C:Usersrichmvcapp Now listening on: http://localhost:5000 Application started. Press Ctrl+C to shut down. Application is shutting down...
You can now reference .NET Framework libraries from .NET Standard libraries using Visual Studio 2017 15.3. this scenario is more nuanced than is typical. It can be thought of as a feature that 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 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.
The following is an example nuspec (recipe for a NuGet package) targeting .NET Standard 1.4.
Please try out .NET Core 2.0 Preview 2. We are collecting feedback in the dotnet/core #711 issue. We are continue to improve the .NET Core 2.0 release and are relying on feedback to direct our efforts.
We recently released .NET Application Architecture Guidance. You can use these guides to get practical advice, best practices, and sample applications for using .NET with microservices, Docker containers, Kubernetes, Xamarin, ASP.NET, Azure, Service Fabric, and more.