What’s New in ASP .NET Core 2.2 Right Now
The main theme for this ASP.NET Core release was to improve developer productivity and platform functionality with regard to building Web/HTTP APIs. So what’s new in ASP .NET Core 2.2 right now? First of all, you can work with ASP .NET Core 2.2 in the latest version of Visual Studio 2017 or VS Code with the .NET Core 2.2 SDK. There are many cool new features, notably:
- New Health Checks API
- Improved Open API (Swagger) Integration
- Client-side template updates (Bootstrap 4, Angular 6)
- SignalR Java Client
- HTTP/2 Server Support (Preview)
- Improved perf: IIS throughput, MVC model validation + routing, HTTP Client
Health Checks integration with BeatPulse
We’re happy to announce that the BeatPulse project now supports the new Health Checks API, which means you can easily add checks for dozens of popular systems and dependencies using their great support. Here’s a message from the BeatPulse team about their support for our new Health Checks API:
BeatPulse is a community driven project that was created to provide health checking mechanisms for systems, networking and a wide variety of services that are common within the enterprise, e.g. SqlServer, MySql,Postgress, Redis, Kafka and many more . When Microsoft announced ASP.NET Core Health Checks for the 2.2 roadmap, the BeatPulse team ported all the existing liveness packages and features to work with the new Microsoft Health Checks abstractions at the repository AspNetCore.Diagnostics.HealthChecks. Apart from all the health checking packages, the BeatPulse team also incorporates other features like pulse tracking (Application Insights and Prometheus), failure notifications and a UI interface were we can configure different monitored systems and have a global view of health status. This UI is available as a Docker image published in Docker Hub.
More coming soon
When we announced planning for ASP.NET Core 2.2, we mentioned a number of features that aren’t detailed above, including API Authorization with IdentityServer4, Open API (Swagger) driven client code generation, and the HTTP REPL command line tool. These features are still being worked on and aren’t quite ready for release, however we expect to make them available as add-ons in the coming months. Thanks for your patience while we complete these experiences and get them ready for you all to try out.
Migrating a project to ASP.NET Core 2.2
To migrate an ASP.NET Core project from 2.1 to 2.2, open the project’s .csproj file and change the value of the TargetFramework
element to netcoreapp2.2
. You do not need to do this if you’re targeting .NET Framework 4.x.
Finish by updating your NuGet package references to the latest stable versions. Note that projects targeting .NET Core (rather than .NET Framework) should not have a package version specified for the Microsoft.AspNetCore.App package reference as this will be managed automatically by the SDK. Doing so will now result in a build warning.
Update Target Framework Moniker (TFM)
Projects targeting .NET Core should use the TFM of a version greater than or equal to .NET Core 2.2. Update the <TargetFramework>
node’s inner text with netcoreapp2.2
:
<TargetFramework>netcoreapp2.2</TargetFramework>
Projects targeting .NET Framework may continue to use the TFM of a version greater than or equal to .NET Framework 4.6.1:
<TargetFramework>net461</TargetFramework>
Adopt the IIS in-process hosting model
To adopt the in-process hosting model for IIS, add the <AspNetCoreHostingModel>
property with a value of InProcess
to a <PropertyGroup>
in the project file:
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
Update .NET Core SDK version in global.json
If your solution relies upon a global.json file to target a specific .NET Core SDK version, update its version
property to the 2.2 version installed on your machine:
{
"sdk": {
"version": "2.2.100"
}
}
Update package references
If targeting .NET Core, remove the Version
attribute for the metapackage reference. Inclusion of a Version
attribute results in the following warning:
A PackageReference to 'Microsoft.AspNetCore.App' specified a Version of `2.2.0`. Specifying the version of this package is not recommended. For more information, see https://aka.ms/sdkimplicitrefs
The metapackage reference should resemble the following <PackageReference />
node:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
If targeting .NET Framework, update each package reference’s Version
attribute to 2.2.0 or later. Here are the package references in a typical ASP.NET Core 2.2 project targeting .NET Framework:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.CookiePolicy" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.HttpsPolicy" Version="2.2.0"/>
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />
</ItemGroup>
Update compatibility version
Update the compatibility version in Startup.ConfigureServices
to Version_2_2
:
services.AddMvc()
.SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
Update Docker images
The following table shows the Docker image tag changes:
2.1 | 2.2 |
---|---|
microsoft/dotnet:2.1-aspnetcore-runtime |
microsoft/dotnet:2.2-aspnetcore-runtime |
microsoft/dotnet:2.1-sdk |
microsoft/dotnet:2.2-sdk |
Change the FROM
lines in your Dockerfile to use the new image tags in the preceding table’s 2.2 column.
Support life cycle
ASP.NET Core 2.2 is the latest release in the “Current” .NET Core train. This represents the first release since the declaration of 2.1 LTS that reestablishes a separate LTS and Current train. The Current train is where new features, enhancements, and regular bug fixes are applied and is recommended for most customers. Note that both LTS and Current releases receive servicing updates for security and critical stability fixes. It is currently expected that 2.2 will the last non-servicing release in the 2.x life cycle, and as such customers not using an LTS release will need to migrate to 3.0 GA, within 3 months of its release in the second half of 2019 in order to remain supported.
Every Microsoft product has a lifecycle. The lifecycle begins when a product is released and ends when it’s no longer supported. Knowing key dates in this lifecycle helps you make informed decisions about when to upgrade or make other changes to your software. This product is governed by Microsoft’s Modern Lifecycle Policy.
The .NET Core support lifecycle offers support for each release. The length of time and degree of support vary based on a few qualifications.
What releases qualify for servicing and how do updates effect servicing qualifications?
Within a release’s support lifecycle, systems must remain current on released patch updates for the Major and Minor release.
Customers can choose to use the Long Term Support (LTS) releases or Current releases. LTS releases will generally receive only critical fixes throughout their lifecycle. Current releases will receive these same fixes and will also be updated with compatible innovations and features.
Long Term Support (LTS) releases
LTS releases are supported for the following timeframe, whichever is longer:
- Three years after initial release.
- One year after a subsequent LTS release.
Note: .NET Core 1.x was released under an earlier definition of LTS.
Current releases
- Three months after a subsequent Current or LTS release
How do the different support tracks work?
Customers using LTS will need the latest patch update installed to qualify for support. If a system is running 1.0 and 1.0.1 has been released, 1.0.1 will need to be installed as a first step. Once a patch update has been installed applications will begin using the update by default. LTS releases will be supported for 3-years after general availability, or for a 12 month Maintenance period after the next LTS release ships, whichever is longer.
In addition to staying current with the latest patch update, customers using Current will need to update as new minor versions are released. The latest released minor version will become the minimum serviceable baseline after release. After a 3 month Maintenance period, the previous minor version will no longer be supported. For example, after 1.2 releases systems running version 1.1 will have 3 months to update to 1.2 to remain eligible for support. Applications do not automatically begin using the new minor update.
End of support
End of support refers to the date when Microsoft no longer provides fixes, updates, or online technical assistance. End of support may also be referred to as ‘end of life’ or abbreviated ‘EOL’. This is the time to make sure you have the latest available update* installed. Without Microsoft support, you will no longer receive security updates that can help protect your machine from harmful viruses, spyware, and other malicious software that can steal your personal information.
* Updates are cumulative, with each update built upon all of the updates that preceded it. A device needs to install the latest update to remain supported. Updates may include new features, fixes (security and/or non-security), or a combination of both. Not all features in an update will work on all devices. Update availability may vary, for example by country, region, network connectivity, or hardware capabilities (including, for example, free disk space).
Availability in Azure App Service
The .NET Core 2.2 SDK, runtime, and updated ASP.NET Core IIS Module are in the process of being deployed to Azure App Service regions around the world. We expect this to be completed before the end of December 2018.
Some regions may receive the updated runtime before the updated ASP.NET Core IIS Module (ANCM), which is required by default for projects targeting ASP.NET Core 2.2. It’s also a requirement for the new in-process hosting feature. If you receive startup errors after deploying to Azure App Service, try configuring your project to use the existing version of ANCM by setting the AspNetCoreModule
property to the value “AspNetCoreModule”, e.g.:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>
Once the target region has been updated with the latest ANCM version, you can remove that property altogether and redeploy the application to have it switch to using the new ANCM.
This release also adds better 64-bit support for .NET Core in Azure App Service. If you’re running your ASP.NET Core application on .NET Core 2.2 with in-process hosting, you can simply enable the 64-bit option in the Azure Portal and the site will now run in a 64-bit process.
Best and Cheap ASP.NET Core 2.2 Hosting
ASPHostPortal Review | Website: http://asphostportal.com/ |
---|---|
Reputation | |
Features | |
Speed | |
Reliability | |
Support | |
Price | $3.81 /mo, 15% off $4.49 /mo regularly |
Price
The price of ASPHostPortal Windows shared web hosting is starting at $4.49/mo regularly. However, with the purpose of helping customers save more money, the company is now offering an attractive discount with which the plan starts at $3.81/mo only for all customer. To be honest, this price is really affordable and competitive in the industry considering the rich features provided.
Billing Cycle | Regular | Discounted | Discount |
5 Years plan | $4.49/mo | $3.81/mo | 15% |
3 Years plan | $5.79/mo | $4.92/mo | 15% |
1 Year plan | $6.79/mo | $5.77/mo | 15% |
3 months plan | $7.99/mo | - | - |
Risk-Free Online Deal
As the majority of web hosts in the market only provides customers with a 15 days refund period, ASPHostPortal offers a long term money back guarantee, which is up to 30 days.
Note that the 30-day refund is available for new customers who purchase all hosting package. Once customers are dissatisfied with the hosting services and want to cancel the account, they can get all of their money back.
To do this, customers only need to send the cancellation requests to sales through e-mail. Do remember that these requests should be made with the day of the cancellation, the billing username, last four digits of billing password, as well as the domain name available in the e-mail.
Features
ASPHostPortal is one of the most rich-featured hosting providers, offering a large set of technologies as well as the competitive highlights. We have listed some of the typical features in the following, all of which can bring great benefits.
Core Specs | Database Specs | Email Specs |
Host Unlimited Sites | 2 SQL Server db | 200 MB Email Space |
5 GB Disk Space | SQL Server 2008/2012/2014 | Unlimited POP3/SMTP |
60 GB Bandwidth | SQL Server 2016 | Unlimited Domain Aliases |
Unlimited SubDomains | 200 MB SQL Server / db | Unlimited Domain Forwarders |
Dedicated Application Pool | Remote DB access | Unlimited Auto Responders |
Support UTF-8 Domains | SQL Mgmt Studio Exp tool | SmarterMail Access |
US/France/Netherlands Server | 3 MySQL db | Catch All |
Singapore/Australia Server | 200 MB MySQL / db | 0 Mailing Lists |
UK/Italy/Germany Server | MySQL Web-Based Access | |
India Server | Unlimited Ms Access |
Technical Support
As one of the most reliable hosting companies, ASPHostPortal offers quality technical support powered by a group of support staffs through email, all of who are professional, knowledgeable, experienced and on-site 24×7, so that they are able to give quick response and effective assistance to troubled customers to resolve problems.
In addition, in their online knowledgebase and blog, ASPHostPortal technicians and engineers have worked out a lot of in-depth articles to teach customers how to deal with common issues independently.