Development With A Dot

When using Anti Cross Site Scripting Forgery (XSRF) protection in your application, which is on by default, you may be surprised when you try to AJAX submit to a controller and you get a HTTP 400 Bad Request: this may be happening because the framework is blocking your request due to XSRF.

When performing file upload(s) to an asynchronous action, it may happen that the uploaded file(s) may not be accessible, resulting in an ObjectDisposedException. This is because the uploaded files are saved to the filesystem temporarily by ASP.NET Core and then removed, after the request has been processed, which is generally what we want. If we issue an asynchronous task with an uploaded file and don’t wait for it to finish, it may happen that it occurs outside of the request’s scope, meaning, the uploaded file is already gone.

The most common way to show an image in an HTML page is to use the <img> tag to load an external resource. Another option is to use a URL that is a Base64 encoded version of the image. There are some aspects worth considering:

The way I see it, there are three reasons for using an Inversion of Control (IoC) / Dependency Injection (DI) container:

As you can imagine, it doesn’t make much sense to have a service that is registered as singleton to depend on another service that is registered as scoped, because the singleton instantiation will only happen once. Take this example:

Last update on March 25th. Reversed order, latest ones first.

In pre-3.1 versions of ASP.NET Core, you could return your own service provider (AutoFac, Ninject, etc) by returning some IServiceProvider-implementing class from the ConfigureServices method. This is no longer supporting, and having code like this results in an NotSupportedException being thrown at startup:

When localizing a web application using resources, there are two common ways: