Using .NET Core Data Protection is a bit limited. I like how it generates keys and can maintain them, but the storage mechanisms out of the box are fairly limited. Unless you’re using Redis or Azure Stoage, your only option is file system persistence. This isn’t really usable for distributed applications that need to share keys. Ideally, using a SQL server backend would be available, but it’s not too terribly difficult to create one.
.NET Core doesn’t have built-in support for LDAP (Active Directory). This can be a show-stopper for a lot of projects. It was a bit of a show-stopper for me earlier as well.
So, references to these libraries won’t be available:
But, there are alternatives to mitigate the problem.
Over the past weekend, I was playing around with deploying .NET Core Docker images to Amazon AWS. I wanted to utilize their EC2 Container Repository (ECR) to keep everything self-contained. My initial tinkering turned out pretty well. I’ll have a better walk-through once I have everything working as I want.
At any rate, here are a few notes I made to myself for the steps I went through, which I thought I’d share. These steps detail building/deploying Docker containers to AWS using EC2 with the EC2 Container Repository (ECR). Docker images were made directly from VS2017 using Docker CE (Docker Compose).
Earlier today I was running into weird issues detecting whether or not my .NET Core site was receiving HTTPS requests. After much gnashing of teeth, I believe I found a solution.
Microsoft’s guidance, in regards to deploying .NET Core applications to IIS, is a bit lacking. Throw in a continuous integration tool, like Team City, and it becomes a bit of trial and error to get a .NET Core app deployed to an IIS hosted instance.
Exceptions in .NET can be difficult to log or inspect due to their hierarchical nature with inner exceptions. Since the InnerException on a given exception is not an enumerated list, it requires a little bit of work to flatten the hierarchy.