10 posts tagged with "ASP.NET Core"

Using the [Options pattern in ASP.NET Core] allows you to benefit from [Options validation], but this only fires the first time the configuration is accessed. The Options Pattern is build on top of Configure and OptionsBuilder.Bind(IConfiguration config) will actually call Configure(IConfiguration config) directly, so they are also equivalent. Both methods do the same job but AddOptions came later and allows more customizations. It would be much better to prevent a service starting if there are configuration values missing or with invalid values. Such functionality is not provided by the framework as of .net5.0, the GitHub issue [Options Validation: support eager validation] remains open. The following method of Options Validation is taken from [Baget] with small modifications to allow sharing the implementation with multiple services. You can get the full working demo from my GitHub repo. [Options pattern in ASP.NET Core]:

A Route is the inbound URL which the reverse proxy is going to act on. The cluster is a list of potential destination URLs.

Even with next to no configuration or additional work on your API Swagger already provides great insights into your API. To give consumers of the API even more information on what to expect from the API you can add annotations to

In Part one we setup the health check endpoints, now to add a frontend.

To secure Health Checks it is possible to make them available on internal addresses only, and on a different port to the publicly served pages/API endpoints.

First we need to make the service available over 2 different ports. This can be achieved by adding a Urls value to appsettings.json.

{
	"Logging": {
		"IncludeScopes": false,
		"LogLevel": {
			"Default": "Debug",
			"System": "Information",
			"Microsoft": "Information"
		}
	},
	"Urls": "http://localhost:1114;http://localhost:1115",
	"ManagementPort": "1115",
	"ConnectionStrings": {
		"LoginServiceDb": "Data Source=.,11433;Initial Catalog=LoginServiceDatabase;Integrated Security=true;"
	}
}

This can be done in several ways, and is described in more detail by Andrew Lock in his post 5 ways to set the URLs for an ASP.NET Core app.

Now when you debug the service you should see in the log that it is listening on 2 ports.

info: Microsoft.Hosting.Lifetime[0]  Now listening on: http://localhost:1114
info: Microsoft.Hosting.Lifetime[0]  Now listening on: http://localhost:1115
info: Microsoft.Hosting.Lifetime[0]  Application started. Press Ctrl+C to shut down.

This follows on from my previous post Secure ASP.NET Core Health Checks to a specific port and assumes that you already have your service running over 2 ports and have specified a ManagementPort in the appsettings.json file.

Running ASP.NET Core on a RaspberryPi 2 with Nginx​

I followed the instructions from Get Started and docs.microsoft.com, and found that some additional configuration was required.