Motivation​

Suppose you work on ASP.NET Core web application that solves some business-related tasks. You know, a few forms where users enter their data and get some reports. Although such a project may not require any complex logic on the client, you still probably need to write some JavaScript code to make user interaction with your application more convenient and enjoyable. For example, you may need a simple prompt popup on item deletion since it's not quite right to use a separate page for that. Or, you want to do client-side validation. Or ... it really can be any other client-side task, you name it.

Introduction​

There are many ways to create a web application today. We have a lot of different platforms, frameworks, and libraries: PHP, Python, Java, NodeJS, and a dozen of others.

While ASP.NET (Core) was always a good choice for developing enterprise-level web applications (with many complex web pages, some Web API endpoints, static resources, etc.), it's never been the best choice for creating a small web service with just a few endpoints to handle REST API requests in JSON or plain text formats.

Well, that was true until .NET 5 was released last year. With support for top-level statements and new features in C# language, .NET 5 allows us to create a solid web service in just a few minutes and with a single code file.

Implementing CRUD operations in your ASP.NET Core application can be a very tedious and time-consuming task. EasyData helps to add all necessary functionality (and even more) in a matter of minutes.

Problem​

One of the first tasks for most business applications is to implement CRUD (Create, Read, Update, Delete) operations for the main entities the app works with.

Every developer faces the following problems as part of solving the task:

• The creation of CRUD pages and forms is very boring and time-consuming. Believe me, I’ve been there a lot of times.

• If you do it manually, it can be very slow and error-prone (missed fields, forgotten validators, etc).

• Of course, you can use the scaffolding tool provided by Visual Studio. However, it’s also not a quick process either, because you need to run that tool for each model class. As a result, you get many .cs and .cshtml files, which you'll have to edit manually if something in the default behavior or appearance doesn't suit your needs. In the event of changes in the model classes, you'll need to update those generated controllers and pages manually or regenerate the code and forms from scratch for each affected model class.

• Moreover, even the built-in scaffolding doesn't provide some important, often essential functions such as paging or search.

This is the second part of the article, where we take apart the default ASP.NET Core solution template piece by piece and try to explain the purpose of each part and how exactly it works. You can consider it as a reference where you can check why a particular part was added to your project and find a link to the relevant documentation that explains it in detail.

Startup class​

As we already mentioned in the first article, the Startup class is the entry point for all initialization codes in your application. Long story short, the Startup defines what your application will do and how exactly it will work.

Choosing a framework is not easy when you start reflecting on your future as a software developer, especially if you are a newbie. Mastering any programming language takes long hours and an effort you don’t want to waste. And it’s stressful to think that the wrong option might lead you to a job where you will have to change your knowledge base again.

Ok, let’s switch to the positive side. Since you are here, your options are narrowed down to these two: Java or .NET. That’s already a huge move forward. Both options are already a kind of win. Java and .NET are both well-established and are used for enterprise-level development. That means you might land a job at a huge company with lots of resources and opportunities.

The concept of Dependency Injection can look over complicated especially for beginners. Here, I have tried to explain it by using a very simple example from the real world: a food delivery app on your mobile phone.

So, imagine you open such an app on your smartphone. Let’s see what we have here:

Introduction​

This is a second edition of the [previous post on the same topic]({{ 'ancid01' | internal_path }}). The reason why I wrote this one is because of some drastic changes made in ASP.NET Core Authentication system from version 2.0 to version 2.2 - so most of the code presented in the first article doesn't work with the new version.

So, the code in the following articles was built for and tested with ASP.NET Core 2.2. The main concept, however, is still the same and were not changed since ASP.NET Identity 2.0 (I guess).

As in the previous case, we will start with a description of the problem.

Quite often when you are writing tests it's necessary to store some data together with the testing project to make them available in the test functions.

Problem​

Sometimes, when you build a multi-tenant web-application you may need to set up a "master password" to your system - the password which allows some administrator to login to any user's account. Something similar to su command in Unix/Linux systems.

This is a third part of the series of articles about some not-so-well-known features and tricks in ASP.NET Identity. Here are you can find the [first]({{ 'ancid05' | internal_path }}) and the [second]({{ 'ancid02' | internal_path }}) parts.

Problem​

This task usually appears when you need to transfer your old MVC web application to ASP.NET Core. If you use MVC version 3 or 4 and your application provides a user authentication service, then most likely this part is done with the old ASP.NET Membership library.

So, imagine you have a bunch of users, each of them has some password and the hash of that password stored in some database. Now you need to transfer all your current users to the new system built with ASP.NET Core. Of course, it's not a big problem to transfer their names, addresses, and other information. The problem is in those password hashes. ASP.NET Core Identity uses another hashing algorithm so all current users will not be able to access the system with their old passwords - the hashes will not match.