Exercises in .NET with Andras Nemes

Introduction to ASP.NET Core part 4: middleware and the component pipeline

Introduction

In the previous post we saw how to add a configuration file to an ASP.NET Core application and how to extract the various settings from it. We now know that the traditional web.config file has been replaced by appsettings.json and JSON is used in favour of XML. We also demonstrated that retrieving the settings values is achieved in a very different way compared to how it was done before. The ConfigurationBuilder object with its various extension methods help us load and read the configuration settings. In addition, various techniques such as using the generic IOptions of T interface let us process the different sections in appsettings.json so that we only distribute those settings that are relevant to the consuming classes that they really need. This is in contrast to passing the full list of configuration key-value pairs everywhere. The consuming class can then read the settings in an object oriented way from specialised options objects.

In this post we’ll start looking at middleware and the component pipeline in .NET Core. We’ll also write a simple custom middleware.

Read more of this post

Introduction to ASP.NET Core part 3: the configuration file

Introduction

In the previous post we looked at how dependencies and dependency injection work in .NET Core. New libraries can be downloaded to the solution in various ways: through the NuGet GUI, The NuGet package manager console, by editing project.json directly or letting Visual Studio figure out if a certain library could solve a missing reference problem. Dependency injection can be achieved through a built-in IoC – Inversion of Control container – where we register the abstractions and the corresponding dependencies in Startup.cs. We can give various lifetimes to the dependencies: transient, scoped and singleton. Then whenever a class requires a dependency the IoC container will serve up the registered concrete implementation automatically.

In this post we’ll see how to add a configuration file to the project and how to read from it.

Read more of this post

Introduction to ASP.NET Core part 2: dependencies and dependency injection

Introduction

In the previous post we started looking at the anatomy of an ASP.NET Core application. .NET Core is a cross-platform, highly modular and lightweight application framework that is meant to be the future of application development in .NET. We identified some significant changes compared to traditional ASP.NET applications that we saw before. There are a couple of new JSON files such as global.json and project.json. Global.asax.cs is gone and has been totally replaced by Startup.cs. There’s still a web.config file but it’s not used for the same kind of configuration as before. A different json file which we haven’t seen yet will be used for that purpose. The file structure is also different in that the source files are stored in a folder called “src” by default. Note that .NET Core is still in preview mode at the time of writing this series.

In this post we’ll look at adding dependencies and using them via dependency injection and service registration.

Read more of this post

Introduction to ASP.NET Core part 1: anatomy of an empty web project

Introduction

ASP.NET Core is a brand new portable web framework by Microsoft. It is similar to the “normal” ASP.NET versions we’ve seen so far, such as ASP.NET 4.5. ASP.NET 4.5 targets the .NET 4.5 framework and conversely ASP.NET Core is primarily targeted at the .NET Core framework. However, it can also target the other .NET frameworks like .NET 4.5 or 4.6. It is currently in preview mode at the time of writing this post but developers are free to play around with it already now. It’s good to get familiar with the new features because .NET Core is meant to be the future direction of .NET development. There’s a number of significant changes compared to the earlier versions of ASP.NET that .NET developers will need to get used to.

Currently .NET Core is a subset of the full-blown .NET framework meaning that not all features of .NET are available in it. However, as the product matures the gap between .NET Core and full .NET should diminish. Eventually all new .NET projects should target .NET Core.

.NET Core marks a significant shift from Microsoft’s past policies and attitude of targeting Windows only and keeping as much as possible secret and paid. .NET Core is cross-platform and designed to run on multiple operating systems: Windows, Mac OS and Linux. It is also open-source, you can view its public GitHub repository here.

Read more of this post