C# 9 gives you a better way to create value objects and some simpler code to use while doing it. But even if you don't care about value objects, the new keyword has some cool changes.
You're missing out on some cool features if you're building applications in .NET Core 3 and not exploiting the new features in C# 8. Here's what Peter thinks are the ones you'll find most useful.
Thanks to Chris Sainty and Remi Bourgarel, working with local storage from a Blazor application running either in the browser or out of it is relatively easy. Testing your code can be equally easy but only if you set up support the real world of network connections.
Right now, in Visual Studio, you can create a solution that takes a single UI with its code and shares it across Windows, Android, macOS, iOS and web browsers. It's not a perfect cross-platform solution (yet), but it's here now.
Really, you only need to do two kinds of testing: Unit testing (to make sure that your individual components work) and end-to-end testing (to make sure your application works). Anything else is just a waste of your time.
GraphQL gives clients who call your Web services the ability to specify what properties of your data objects they want. Here are two ways to let those clients also specify which data objects they want.
GraphQL lets you create data access services without writing controllers. Instead of writing procedural code, you declare schemas describing what queries you'll accept and what you're willing to return. Here's how to get started in ASP.NET Core.
ASP.NET Core Version 3.1 adds some new features for managing events in Blazor. You may think you'll never need them, but there may be a time when you'll be glad to know about at least one of them.
ASP.NET Core Version 3.1 has at least two major changes that you'll want to take advantage of. Well, Peter thinks you will. Depending on your background, your response to one of them may be a resounding “meh.”
If you're creating business services that send dates and decimal data then you may be concerned that gRPC services don't support the relevant data types. Don't Panic! There are solutions. Here's how to use them.
In the real world, you've been dealing with the State pattern every time you designed a set of database tables. The Protocol Buffers specification lets you do the same thing when you define the messages you send and receive from your gRPC Web Service.
Here's everything you need to know to create a standard set of reusable message formats to use with your gRPC services.
Peter's pretty fanatical about replacing documentation/comments with readable code. So he's very excited about using enums when defining gRPC services. Very. Excited. But there are some best practices and "things to be aware of" when using this feature.
Defining your gRPC service using the Protocol Buffers specification is pretty easy. There are just a couple of things to be aware of as you convert from the specification to .NET Core and then manage your service's evolution.
When you need to integrate authorizing the user to perform some activity (or just want to retrieve information about the current user), you need to work with the ClaimsPrincipal’s Claims objects. Here’s everything you might want to do.