For a .NET Core 2.0 project, I used Microsoft standard health check libraries which are clearly documented based on code for .NET Core 2.0. Since less than a month, suddenly, this is deprecated. The new readme file, refers to an alternative for .NET Core 2.2 .However, the version of .NET Core that is production ready, recommended and has long term support, is version 2.1 which is exactly what I use now for a new project.
So I am in trouble. What is the supported way of implementing health checks for .NET Core 2.1? This used to be clear for .NET Core 2.0 and shall be clear for .NET Core 2.2 but for .NET Core 2.1 it is unclear what I should do.
You answered your own question actually, with the reference links.
ASP.NET Core 2.2 comes with its own official heath check, see Docs and the ASP.NET Core 2.2.0-preview1 blog post for the new health service.
You can use either one (2.2 or your old solution) for the ASP.NET Core 2.x life-time. Since the old one is deprecated it won't be updated for newer versions of ASP.NET Core, but you should expect it to work for the 2.x lines.
By the time ASP.NET Core 3.0 is out and you want to migrate to it, you should switch to the health services introduced in ASP.NET Core 2.2.
General consensus about new features in minor versions (which replace or change previous behavior) is to support them for the current main version and drop the old functionality in the next major, i.e. the new [ApiController] attribute and automatic model validation was added in ASP.NET Core 2.1. By default, the 2.0 compatibility will be used and the new behavior won't be available unless you opt-in. Once 3.0 is released, the old features/behavior will be removed and only the new one will be used.
Related
In .NET framework we have support of Creating Help Page for Web API.
https://learn.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages
Does this feature supported in .NET 6. We are migrating our legacy ASP.NET framework application to .NET6.
How to migrate this feature to .NET6? If it is not supported in .Net6(.net core) how can we achieve the similar functionality in .Net core
I am trying to migrate this feature to .net core but I am facing issues on how to load the app data, register HelpdataConfig in .net core.
ITNOA
As you can see in ASP.NET help page for ASP.NET Core Web API, the Microsoft.AspNet.WebApi.HelpPage is for ASP.NET and does not for ASP.NET CORE or .NET 6, so you have to migrate this library to some popular Web API documentation libraries like Swagger
As you can see in ASP.NET Core web API documentation with Swagger / OpenAPI, you can use below documentation
By Christoph Nienaber and Rico Suter
Swagger (OpenAPI) is a language-agnostic specification for describing REST APIs. It allows both computers and humans to understand the capabilities of a REST API without direct access to the source code. Its main goals are to:
Minimize the amount of work needed to connect decoupled services.
Reduce the amount of time needed to accurately document a service.
The two main OpenAPI implementations for .NET are Swashbuckle and NSwag, see:
Getting Started with Swashbuckle
Getting Started with NSwag
Our app is based on ASP.NET Core 2.0. It works fine in development environment but we see an oauth error when published to production.
All the documentation on asp.net core seems to point to using ILoggingxxx interfaces. The examples I found typically call logging.AddConsole() method so that the log lines can be viewed in VIsual Studio debug window. I am wondering if the good old trace.axd is still available under asp.net core. If so, I would appreciate the steps to enable tracing. Regards.
trace.axd is exclusive to applications based on .NET Framework and ASP.NET 4.x. It is not available in ASP.NET Core applications at all.
With ASP.NET Core 1.0 release one can run on either .NET Core or the full .NET Framework per the documentation here. I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I understand the difference between the full .NET Framework and .NET Core. However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6? I thought the idea was a 1-2 punch with ASP.NET Core atop of .NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc. Without .NET Core I don't believe anything on that list is still valid, so what is the use case for the full .NET framework + ASP.NET Core? What does ASP.NET Core on it's own still provide to me without .NET Core?
.NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc.. Without .NET Core I don't believe anything on that list is still valid
The only benefit you don't have if you choose the full .NET framework over .NET Core is being cross platform. All the other benefits of deployment, modularization, docker, performance, etc... are still valid.
We actually run our ASP.NET Core web app on the full framework and now we enjoy the benefits of having Dependency Injection as a 1st class citizen, having NuGet built in, having an lean HTTP request pipeline which makes our performance better, open sourced (so all the issues can be solved by a short visit to GitHub), modularity (still have to come across something we couldn't customize to our own needs after almost a year now), and so on. And we know we don't need to deploy on any other OS than Windows, so we can still have all the benefits of the full framework.
Update from Tseng
Well, you can still target full .NET Framework under Linux for example. There you need mono 4.6 installed there. There are some limitations as not all classes are implemented in mono, but a majority is and around the corner case (i.e. encryption) you have to work around
Update from atconway
It's also worth noting at the time VB.NET is not supported by .NET Core if that's a requirement.
However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6?
If I use ASP.NET 4.6 instead of ASP.NET Core 1, then I won't be able to use ASP.NET Core MVC. None of the features on that documentation page would be made available to me! I would have to build an MVC5 application. Boooo!
I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I'm assuming that another way to ask this would be: "why would you take the red path when you can take the brown path?"
One argument for doing it this way is deployment. If you've got a bunch of existing Windows servers with IIS on them, you're going to need to install additional software on each of them and set them up to run Core applications. IIS just becomes a reverse proxy for your .NET Core app.
However, if these apps were built on the .Net Framework instead, you wouldn't have to do this. You could still use web deploy (for example) to move them onto the servers. Maybe you've got some other existing IIS configuration settings that you don't want to migrate.
Using ASP.NET Core 1.0 targeting the .Net Framework, you can get the benefit of the new features in ASP.NET Core MVC without having to change your existing infrastructure.
One important benefit of using Full .NET framework with Asp.Net core is availability of mature libraries and frameworks that are developed mainly to target previous version of .NET.
But by passing of time and implementing more and more libraries to target .NET core and developing more features for .NET core itself this benefit may fade out.
Having to leverage legacy technologies like OLE DB that will never be implemented in NET Core System.Data is another reason.
One thing to consider is that it can be a migration path. Say, for example, you have an existing ASP.NET 4.6 application that you intend to migrate to .NET Core. You want to take advantage of ASP.NET Core features like TagHelpers, Dependency Injection, etc., but you aren't ready or able to use .NET Core framework. So, you develop the ASP.NET Core application, targeting just the .NET full framework. Then, you take the next step and multi-target, going for both .NET full framework and .NET Core framework. This gives you the flexibility to easily deploy to IIS with the full framework or cross-platform with the core framework. From there, you can decide if you want to eliminate the full framework or not.
I am trying to provide authorization to the user, using DocumentDb at the backend - But I am unable to find any resources regarding the same. The documentation provided is for SQL based ones (https://docs.asp.net/en/latest/security/authentication/identity.html).
Any help?
To provide you with a starting point, there are several important issues to bear in mind when looking at using Identity with ASP.Net Core:
Framework Compatibility
You mention that you will be using ASP.Net Core, and this can be used with either .Net Core, or the 'full' .Net Framework (e.g. .Net Framework 4.5.1), which can be specified in your project.json under the frameworks property.
The Microsoft DocumentDB native .Net client does not support .Net Core; so, you must configure ASP.Net Core to target the 'full' .Net Framework. If you are unsure how to do this, you can create a new project in Visual Studio 2015, and select the 'ASP.Net Core (.Net Framework)' Project Template; the project.json will have its framework property correctly configured for you.
'Identity' Version
There are several versions of ASP.Net Identity; be aware when selecting a provider, that most currently reference ASP.Net Identity 2.2.1; however, the latest version is 3, released alongside ASP.Net Core, supported by the NuGet package Microsoft.AspNetCore.Identity 1.0.0, which has some differences and additional features. (Note that you can use this latter package with the full .Net Framework.)
No Official Implementation
Microsoft has decided not to create an official DocumentDB implementation for ASP.Net Identity, citing that 'there are two community projects available' (reference here)
Third-Party Support
Of the available third-party implementations, this one by Adrian Fernandez is the most widely used that provides support for ASP.Net Identity 3 using the Microsoft native DocumentDB client. Samples are included in the GitHub repository. (Please see update below.)
Example Usage
An example of using this DocumentDB provider with ASP.Net, including additional features, can be found here.
An additional example of using ASP.Net Core with the Microsoft DocumentDB provider can be found here.
I have written my own Identity 3 provider for DocumentDB; if I release this on GitHub I will update this answer with a link.
UPDATE 19/04/2017
For those looking for a solution, I now recommend the AspNetCore.Identity.DocumentDb project by Bernhard Koenig. It is feature-complete, includes Unit Tests, and a sample ASP.Net Core project. Also available via Nuget. It supports netstandard1.6 an net46 profiles.
my understanding is the Microsoft made it possible to use Mongo drivers with DocumentDb so maybe you could use this Mongo implementation for asp.net core identity
or google further for existing work that others may have done in this direction.
To implement it yourself you would need to implement at minimum IUserStore and IRoleStore you can also refer to the EF implementations UserStore and RoleStore for inspiration and guidance on implementing those.
The best solution would be using a DocumentDB provider for the .NET Core Identity framework. But there were none so far which is why I created AspNetCore.Identity.DocumentDB and decided to publish it on GitHub under the MIT license.
It is a port of an existing mongodb provider for .NET Core Identity and stores Claims, Tokens & Logins as nested objects. Although one could use DocumentDB with a mongodb interface it's recommended to use the native SDK if possible.
The library is already quite stable and available as a NuGet package.
Notice:
The DocumentDB SDK for C# itself does not support .NET Core as a target platform in the stable release. Fortunately Microsoft is already working on adding .NET Core support and published a preview of the DocumentDB SDK with :NET Standard support at the Connect(); 2016 event.
AspNetCore.Identity.DocumentDB supports both SDKs.
.NET Standard is a specification of APIs that should be available on all .NET runtimes and is currently supported by .NET Core and .NET Framework.
Just wondering how is it with performance is asp.net core in comparison with ASP.NET 4.6. Did someone performance tests?
In generaly ASP.NET Core has much better performance than current ASP.NET 4.x versions. Architecture has changed and ASP.NET Core is no longer based on System.Web.dll (This in itself has a positive effect on performance). Great article about ASP.NET Core performance is on ageofascento.com.
I don't know between 4.6 and Core but here's the ASP.NET Benchmarks repository.
They load test the framework and see at which point it fails. I think what you are looking for is inside one of the Excel spreadsheet in the repository.