When starting with new frameworks that have a lifecycle for their artifacts like components, then you may assume that the lifecycle is strictly linear. In other words, step A comes before step B comes before step C, and so on. Usually, this is the case until it is not. The lifecycle of the Blazor components is not an exception in this matter.
Archive: our articles
Category: ASP.NET Core
Re-Using Angular components in a Blazor WebAssembly application using Angular Elements – Web Components custom elements, FTW!
How To Prepare Your IdentityServer For Chrome’s SameSite Cookie Changes – And How To Deal With Safari, Nevertheless
First, the good news: In February 2020 Google is going to release Chrome 80. This release will include Google’s implementation of ‘Incrementally better Cookies’, which will make the web a more secure place and helps to ensure better privacy for users.
In my last article I explained how the changes in Chrome 80 (February 2020) can break your existing web sites or web applications, because SameSite cookies will be treated differently. In that post I focused on how to correctly set your cookies and how to mitigate incompatibilities between different browsers, as certain Safari versions don’t work correctly with the new way that Chrome enforces.
With the introduction of ASP.NET Core 3.0 the default JSON serializer has been changed from Newtonsoft.Json to System.Text.Json. For projects and libraries switching to the new JSON serializer this change means more performance and the opportunity to rewrite our
If you are using Autofac in your ASP.NET Core application then I recommend to update Autofac to version 4.6.1.
In the previous post “ASP.NET Core in production: Take back control of your web app” I mentioned that getting hold if the dependency injection (DI) is just one step of many to improve the architecture of your web applications. Today well will look into 2 other aspects that are best explained together: graceful shutdown and reacting to aborted requests.
If you register a type as a singleton then you expect just 1 instance of this type in your whole application. What you may not know is that ASP.NET Core is creating 2 instances of
IServiceProvider during building of the
IWebHost that may lead to 2 instance of your “singleton”.
After working with the new ASP.NET Core server
Kestrel and the
HttpClient for a while in a number of projects I run into some performance issues. Actually, it was a throughput issue.
It took me some time to figure out whether it is the server or the client responsible for the problems. And the answer is: both.