a developer's journey with asp.net core and the web
I recently wrote about implementing Windows Authentication with React and .NET Core. Given the length of that post, I found it necessary to keep it bare bones. Today we’re going to talk about expanding our Windows Authentication in NET Core by adding role-based security.
I’ve been using Microsoft .NET for a long time. I started my programming journey learning C# on .NET 1.0 right after it’s initial release. In that time I have only experienced a breaking change twice. Once with WCF configuration in my app.config, and recently with the JSON serialization (or deserialization, as it were). For those upgrading a .NET Core 2.x application to .NET Core 3.x, you’ll want to be aware of some changes in the defaults. Today let’s talk about .NET Core and how it handles JSON serialization (and deserialization).
There are a lot of options out in the wild to add authentication to your application. While OAuth is among the most common, it isn’t your only option. Today I’ll show you how to accomplish Windows Authentication with React and .NET Core in a bare bones fashion.
According to OpenAPI 3.0 it isn’t possible. But what if you really want it to be? Do you have to just settle and allow your Swagger documentation to be wrong? I’m here to show you how to make optional route parameters with Swagger and ASP.NET Core.
Unit testing is the base level of the testing pyramid and thus a vital cornerstone of effective software development. In order to effectively unit test your code you should make use of SOLID design principles and mocking frameworks. That said, it isn’t always easy to accomplish such as mocking IQueryable Extensions.
Developing yourself as a software engineer is important for progression. One tool you should incorporate in your arsenal is unit testing. What are unit tests? Why should I write them? What part do they play in my success or that of my software? Today I’m going to talk about how practicing this principle made me a better developer.
Microsoft recently released .NET Core 3.0 and set the stage for WCF’s exit. .NET Core no longer supports “full framework” mode which effectively ends support for WCF as we know it. Our options for migration vary. Today let’s discuss one such approach I feel is a “low-impact” approach. Let’s look at migrating WCF to gRPC using .NET Core while still maintaining backwards compatibility.
Your software application will crash. Even the most principled software following the best practices will inevitably have a bad day. Figuring out why it crashed and how to prevent it is a skill in and of itself. Fortunately there are steps you can take to help you when this time comes. Application logs are your friend and it is necessary to learn how to read them.
Breathing new life into a “legacy” ASP.NET website is a way you can help slowly transition the site towards ASP.NET Core. One way you might accomplish that is by referencing .NET Standard libraries. Everything seems fine and dandy until you attempt a publish operation. Generally you might not notice these until running msbuild from command-line–such as in a CI environment, batch deploy script, or otherwise. Let’s talk about one major msbuild error you’ll encounter while publishing your ASP.NET MVC application that references a .NET standard library. We’ll also talk about some other errors that might arise in the process.
Recently I was going through the motions upgrading an ASP.NET Core 2.0 website to 2.2. Overall the process was fairly straightforward, minus some gotchas. We were attempting to switch the website from targeting the full framework (net47) to target netcoreapp2.2 but that caused a cascade of problems. One such problem was WCF. Today we’ll discuss using WCF with .NET Core and some of the gotchas you may run into.