Forem: Karthik Chintala

Exploring gRPC project in ASP.NET Core

Karthik Chintala — Mon, 17 Apr 2023 03:30:00 +0000

In this post, we’ll create a new gRPC project in ASP.NET Core and see what’s inside of them.

Why not make an introduction on what is gRPC? Well, there are several introduction posts on gRPC in .NET so I don’t want to write another introduction to the gRPC framework again.

I’ve found some best introduction posts on gRPC in ASP.NET core

Here are some advantages of using gRPC

Lightweight RPC framework, which is language agnostic and works in any environment
Supports bi-directional streaming
gRPC by default uses Protobuf binary serialization, which reduces network usage

Now, Let’s create a new gRPC application in Visual Studio.

Prerequisites

Visual Studio 2022 with ASP.NET and web development workload installed.

Creating a gRPC Server

To create a gRPC server, we have a new template in Visual Studio 2022.

Start Visual Studio 2022 and select Create New project
Search for “grpc” in the search box you should see ASP.NET Core gRPC Service. Select it
Give it a name and in the next screen select .NET 6 and select Create

That should create a brand new gRPC Server application.

Exploring newly created gRPC project

Let’s look at what we have in our solution.

Our newly created solution has a Protos folder with a greet.proto file and a Services folder with GreeterService.cs and a Program.cs file.

Let’s see what we have in each of them.

public class GreeterService : Greeter.GreeterBase
{
    private readonly ILogger<GreeterService> _logger;
    public GreeterService(ILogger<GreeterService> logger)
    {
        _logger = logger;
    }

    public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
    {
        return Task.FromResult(new HelloReply
        {
            Message = "Hello " + request.Name
        });
    }
}

The GreeterService is implemented from Greet.GreeterBase. And we have one method SayHello which overrides the one in the GreeterBase class (we will revisit this class when we see the compiler-generated code later in this blog post).

The SayHello method just wraps the name it got in the request and prepends with Hello and sends it as a response.

Where are the message types declared?

We see HelloReply and HelloRequest types in the GreeterService.cs. Let’s understand what happens.

When we declare a message type in the greet.proto file and save the file in visual studio, the IDE reads the greet.proto file on the fly to generate the required types in a Greet.cs file in <project-folder>\obj\Debug\net6.0\Protos\ folder.

The greet.proto file has HelloReply and HelloRequest types declared and they are not C# classes so we cannot see them in the solution explorer.

You need not worry about the compiler-generated C# code if you are not using Visual Studio 2022. The compiler-generated types will also be created during the build process.

Note: You need not worry about the compiler-generated C# code if you are not using Visual Studio 2022. During the MS Build process, we should get those compiler-generated types.

How does Visual Studio recognize them as types from the proto file?

Let’s quickly search for our HelloReply in Visual Studio 2022.

So, HelloReply and HelloRequest are C# classes under the hood which you won’t see them in solution explorer.

Understanding .proto file

Let’s have a look at our proto file.

syntax = "proto3";

option csharp_namespace = "GrpcTester";

package greet;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply);
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings.
message HelloReply {
  string message = 1;
}

The first line in every .proto file should be the syntax of the proto file. If we don’t do this, the protocol buffer compiler will assume we are using proto2 syntax.

The greet.proto file has an RPC service called Greeter and a method SayHello, which takes in HelloRequest and returns a HelloReply.

And it also has two message types HelloRequest and HelloReply which has name and message properties on it.

Notice how the message type properties are marked with 1 as the value. These are called Field Numbers. If we had more properties on a message type, we’d increment the number count. Like for example

message SearchRequest {
  string query = 1;
  int32 page = 2;
  int32 results_per_page = 3;
}

Why do we need to assign a number to the fields on the message types?

These field numbers have to be unique for each field in the message definition. Because during the serialization process, these filed numbers are the identifiers for the messages in binary format.

For example, if we have a message like this

message Test {
  optional int32 a = 1;
}

And we create a Test message and set the value of a to 150, and we then serialize this message to an output stream, the encoded message will have 3 bytes:

08 96 01

If we use a protobuf decoder and decode it the result will be 1:150 . Here we see field number 1 representing the value 150 (which is our message).

What’s in our compiled C# files from .proto file?

We had 2 message types (HelloRequest, HelloReply) and an RPC service Greeter. Let’s look at what we have in our Protos folder inside obj/debug/net6.0 folder.

We have 2 csharp files. Greet.cs and GreetGrpc.cs. The Greet.cs file holds the message type definitions and GreetGrpc.cs has a server-side implementation of the Greeter, which is the SayHello method declared as part of the service in the proto file.

Here are the Greet and GreetGrpc files.

// <auto-generated>
// Generated by the protocol buffer compiler. DO NOT EDIT!
// source: Protos/greet.proto
// </auto-generated>
#pragma warning disable 1591, 0612, 3021
#region Designer generated code

using pb = global::Google.Protobuf;
using pbc = global::Google.Protobuf.Collections;
using pbr = global::Google.Protobuf.Reflection;
using scg = global::System.Collections.Generic;
namespace GrpcTester {

  /// <summary>Holder for reflection information generated from Protos/greet.proto</summary>
  public static partial class GreetReflection {

    #region Descriptor
    /// <summary>File descriptor for Protos/greet.proto</summary>
    public static pbr::FileDescriptor Descriptor {
      get { return descriptor; }
    }
    private static pbr::FileDescriptor descriptor;

    static GreetReflection() {
      byte[] descriptorData = global::System.Convert.FromBase64String(
          string.Concat(
            "ChJQcm90b3MvZ3JlZXQucHJvdG8SBWdyZWV0IhwKDEhlbGxvUmVxdWVzdBIM",
            "CgRuYW1lGAEgASgJIh0KCkhlbGxvUmVwbHkSDwoHbWVzc2FnZRgBIAEoCTI9",
            "CgdHcmVldGVyEjIKCFNheUhlbGxvEhMuZ3JlZXQuSGVsbG9SZXF1ZXN0GhEu",
            "Z3JlZXQuSGVsbG9SZXBseUINqgIKR3JwY1Rlc3RlcmIGcHJvdG8z"));
      descriptor = pbr::FileDescriptor.FromGeneratedCode(descriptorData,
          new pbr::FileDescriptor[] { },
          new pbr::GeneratedClrTypeInfo(null, null, new pbr::GeneratedClrTypeInfo[] {
            new pbr::GeneratedClrTypeInfo(typeof(global::GrpcTester.HelloRequest), global::GrpcTester.HelloRequest.Parser, new[]{ "Name" }, null, null, null, null),
            new pbr::GeneratedClrTypeInfo(typeof(global::GrpcTester.HelloReply), global::GrpcTester.HelloReply.Parser, new[]{ "Message" }, null, null, null, null)
          }));
    }
    #endregion

  }
  #region Messages
  /// <summary>
  /// The request message containing the user's name.
  /// </summary>
  public sealed partial class HelloRequest : pb::IMessage<HelloRequest>
  #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
      , pb::IBufferMessage
  #endif
  {
    private static readonly pb::MessageParser<HelloRequest> _parser = new pb::MessageParser<HelloRequest>(() => new HelloRequest());
    private pb::UnknownFieldSet _unknownFields;
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public static pb::MessageParser<HelloRequest> Parser { get { return _parser; } }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public static pbr::MessageDescriptor Descriptor {
      get { return global::GrpcTester.GreetReflection.Descriptor.MessageTypes[0]; }
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    pbr::MessageDescriptor pb::IMessage.Descriptor {
      get { return Descriptor; }
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public HelloRequest() {
      OnConstruction();
    }

    partial void OnConstruction();

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public HelloRequest(HelloRequest other) : this() {
      name_ = other.name_;
      _unknownFields = pb::UnknownFieldSet.Clone(other._unknownFields);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public HelloRequest Clone() {
      return new HelloRequest(this);
    }

    /// <summary>Field number for the "name" field.</summary>
    public const int NameFieldNumber = 1;
    private string name_ = "";
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public string Name {
      get { return name_; }
      set {
        name_ = pb::ProtoPreconditions.CheckNotNull(value, "value");
      }
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public override bool Equals(object other) {
      return Equals(other as HelloRequest);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public bool Equals(HelloRequest other) {
      if (ReferenceEquals(other, null)) {
        return false;
      }
      if (ReferenceEquals(other, this)) {
        return true;
      }
      if (Name != other.Name) return false;
      return Equals(_unknownFields, other._unknownFields);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public override int GetHashCode() {
      int hash = 1;
      if (Name.Length != 0) hash ^= Name.GetHashCode();
      if (_unknownFields != null) {
        hash ^= _unknownFields.GetHashCode();
      }
      return hash;
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public override string ToString() {
      return pb::JsonFormatter.ToDiagnosticString(this);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public void WriteTo(pb::CodedOutputStream output) {
    #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
      output.WriteRawMessage(this);
    #else
      if (Name.Length != 0) {
        output.WriteRawTag(10);
        output.WriteString(Name);
      }
      if (_unknownFields != null) {
        _unknownFields.WriteTo(output);
      }
    #endif
    }

    #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    void pb::IBufferMessage.InternalWriteTo(ref pb::WriteContext output) {
      if (Name.Length != 0) {
        output.WriteRawTag(10);
        output.WriteString(Name);
      }
      if (_unknownFields != null) {
        _unknownFields.WriteTo(ref output);
      }
    }
    #endif

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public int CalculateSize() {
      int size = 0;
      if (Name.Length != 0) {
        size += 1 + pb::CodedOutputStream.ComputeStringSize(Name);
      }
      if (_unknownFields != null) {
        size += _unknownFields.CalculateSize();
      }
      return size;
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public void MergeFrom(HelloRequest other) {
      if (other == null) {
        return;
      }
      if (other.Name.Length != 0) {
        Name = other.Name;
      }
      _unknownFields = pb::UnknownFieldSet.MergeFrom(_unknownFields, other._unknownFields);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public void MergeFrom(pb::CodedInputStream input) {
    #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
      input.ReadRawMessage(this);
    #else
      uint tag;
      while ((tag = input.ReadTag()) != 0) {
        switch(tag) {
          default:
            _unknownFields = pb::UnknownFieldSet.MergeFieldFrom(_unknownFields, input);
            break;
          case 10: {
            Name = input.ReadString();
            break;
          }
        }
      }
    #endif
    }

    #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    void pb::IBufferMessage.InternalMergeFrom(ref pb::ParseContext input) {
      uint tag;
      while ((tag = input.ReadTag()) != 0) {
        switch(tag) {
          default:
            _unknownFields = pb::UnknownFieldSet.MergeFieldFrom(_unknownFields, ref input);
            break;
          case 10: {
            Name = input.ReadString();
            break;
          }
        }
      }
    }
    #endif

  }

  /// <summary>
  /// The response message containing the greetings.
  /// </summary>
  public sealed partial class HelloReply : pb::IMessage<HelloReply>
  #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
      , pb::IBufferMessage
  #endif
  {
    private static readonly pb::MessageParser<HelloReply> _parser = new pb::MessageParser<HelloReply>(() => new HelloReply());
    private pb::UnknownFieldSet _unknownFields;
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public static pb::MessageParser<HelloReply> Parser { get { return _parser; } }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public static pbr::MessageDescriptor Descriptor {
      get { return global::GrpcTester.GreetReflection.Descriptor.MessageTypes[1]; }
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    pbr::MessageDescriptor pb::IMessage.Descriptor {
      get { return Descriptor; }
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public HelloReply() {
      OnConstruction();
    }

    partial void OnConstruction();

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public HelloReply(HelloReply other) : this() {
      message_ = other.message_;
      _unknownFields = pb::UnknownFieldSet.Clone(other._unknownFields);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public HelloReply Clone() {
      return new HelloReply(this);
    }

    /// <summary>Field number for the "message" field.</summary>
    public const int MessageFieldNumber = 1;
    private string message_ = "";
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public string Message {
      get { return message_; }
      set {
        message_ = pb::ProtoPreconditions.CheckNotNull(value, "value");
      }
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public override bool Equals(object other) {
      return Equals(other as HelloReply);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public bool Equals(HelloReply other) {
      if (ReferenceEquals(other, null)) {
        return false;
      }
      if (ReferenceEquals(other, this)) {
        return true;
      }
      if (Message != other.Message) return false;
      return Equals(_unknownFields, other._unknownFields);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public override int GetHashCode() {
      int hash = 1;
      if (Message.Length != 0) hash ^= Message.GetHashCode();
      if (_unknownFields != null) {
        hash ^= _unknownFields.GetHashCode();
      }
      return hash;
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public override string ToString() {
      return pb::JsonFormatter.ToDiagnosticString(this);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public void WriteTo(pb::CodedOutputStream output) {
    #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
      output.WriteRawMessage(this);
    #else
      if (Message.Length != 0) {
        output.WriteRawTag(10);
        output.WriteString(Message);
      }
      if (_unknownFields != null) {
        _unknownFields.WriteTo(output);
      }
    #endif
    }

    #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    void pb::IBufferMessage.InternalWriteTo(ref pb::WriteContext output) {
      if (Message.Length != 0) {
        output.WriteRawTag(10);
        output.WriteString(Message);
      }
      if (_unknownFields != null) {
        _unknownFields.WriteTo(ref output);
      }
    }
    #endif

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public int CalculateSize() {
      int size = 0;
      if (Message.Length != 0) {
        size += 1 + pb::CodedOutputStream.ComputeStringSize(Message);
      }
      if (_unknownFields != null) {
        size += _unknownFields.CalculateSize();
      }
      return size;
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public void MergeFrom(HelloReply other) {
      if (other == null) {
        return;
      }
      if (other.Message.Length != 0) {
        Message = other.Message;
      }
      _unknownFields = pb::UnknownFieldSet.MergeFrom(_unknownFields, other._unknownFields);
    }

    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    public void MergeFrom(pb::CodedInputStream input) {
    #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
      input.ReadRawMessage(this);
    #else
      uint tag;
      while ((tag = input.ReadTag()) != 0) {
        switch(tag) {
          default:
            _unknownFields = pb::UnknownFieldSet.MergeFieldFrom(_unknownFields, input);
            break;
          case 10: {
            Message = input.ReadString();
            break;
          }
        }
      }
    #endif
    }

    #if !GOOGLE_PROTOBUF_REFSTRUCT_COMPATIBILITY_MODE
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
    void pb::IBufferMessage.InternalMergeFrom(ref pb::ParseContext input) {
      uint tag;
      while ((tag = input.ReadTag()) != 0) {
        switch(tag) {
          default:
            _unknownFields = pb::UnknownFieldSet.MergeFieldFrom(_unknownFields, ref input);
            break;
          case 10: {
            Message = input.ReadString();
            break;
          }
        }
      }
    }
    #endif

  }

  #endregion

}

#endregion Designer generated code

I know it’s hard to read the Greet.cs file due to boilerplate code.

The Greet.cs file has 3 classes

GreetReflection : Holds the reflection information generated from .proto file
HelloRequest : A partial sealed class that defines our Name property and other boilerplate implementations as HelloRequest inherits from IMessage.
HelloReply : A partial sealed class that defines our Message property and other boilerplate implementations as HelloReply inherits from IMessage.

And this is the GreetGrpc.cs file.

// <auto-generated>
// Generated by the protocol buffer compiler. DO NOT EDIT!
// source: Protos/greet.proto
// </auto-generated>
#pragma warning disable 0414, 1591
#region Designer generated code

using grpc = global::Grpc.Core;

namespace GrpcTester {
  /// <summary>
  /// The greeting service definition.
  /// </summary>
  public static partial class Greeter
  {
    static readonly string __ServiceName = "greet.Greeter";

    [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
    static void __Helper_SerializeMessage(global::Google.Protobuf.IMessage message, grpc::SerializationContext context)
    {
      #if !GRPC_DISABLE_PROTOBUF_BUFFER_SERIALIZATION
      if (message is global::Google.Protobuf.IBufferMessage)
      {
        context.SetPayloadLength(message.CalculateSize());
        global::Google.Protobuf.MessageExtensions.WriteTo(message, context.GetBufferWriter());
        context.Complete();
        return;
      }
      #endif
      context.Complete(global::Google.Protobuf.MessageExtensions.ToByteArray(message));
    }

    [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
    static class __Helper_MessageCache<T>
    {
      public static readonly bool IsBufferMessage = global::System.Reflection.IntrospectionExtensions.GetTypeInfo(typeof(global::Google.Protobuf.IBufferMessage)).IsAssignableFrom(typeof(T));
    }

    [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
    static T __Helper_DeserializeMessage<T>(grpc::DeserializationContext context, global::Google.Protobuf.MessageParser<T> parser) where T : global::Google.Protobuf.IMessage<T>
    {
      #if !GRPC_DISABLE_PROTOBUF_BUFFER_SERIALIZATION
      if (__Helper_MessageCache<T>.IsBufferMessage)
      {
        return parser.ParseFrom(context.PayloadAsReadOnlySequence());
      }
      #endif
      return parser.ParseFrom(context.PayloadAsNewBuffer());
    }

    [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
    static readonly grpc::Marshaller<global::GrpcTester.HelloRequest> __Marshaller_greet_HelloRequest = grpc::Marshallers.Create(__Helper_SerializeMessage, context => __Helper_DeserializeMessage(context, global::GrpcTester.HelloRequest.Parser));
    [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
    static readonly grpc::Marshaller<global::GrpcTester.HelloReply> __Marshaller_greet_HelloReply = grpc::Marshallers.Create(__Helper_SerializeMessage, context => __Helper_DeserializeMessage(context, global::GrpcTester.HelloReply.Parser));

    [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
    static readonly grpc::Method<global::GrpcTester.HelloRequest, global::GrpcTester.HelloReply> __Method_SayHello = new grpc::Method<global::GrpcTester.HelloRequest, global::GrpcTester.HelloReply>(
        grpc::MethodType.Unary,
        __ServiceName,
        "SayHello",
        __Marshaller_greet_HelloRequest,
        __Marshaller_greet_HelloReply);

    /// <summary>Service descriptor</summary>
    public static global::Google.Protobuf.Reflection.ServiceDescriptor Descriptor
    {
      get { return global::GrpcTester.GreetReflection.Descriptor.Services[0]; }
    }

    /// <summary>Base class for server-side implementations of Greeter</summary>
    [grpc::BindServiceMethod(typeof(Greeter), "BindService")]
    public abstract partial class GreeterBase
    {
      /// <summary>
      /// Sends a greeting
      /// </summary>
      /// <param name="request">The request received from the client.</param>
      /// <param name="context">The context of the server-side call handler being invoked.</param>
      /// <returns>The response to send back to the client (wrapped by a task).</returns>
      [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
      public virtual global::System.Threading.Tasks.Task<global::GrpcTester.HelloReply> SayHello(global::GrpcTester.HelloRequest request, grpc::ServerCallContext context)
      {
        throw new grpc::RpcException(new grpc::Status(grpc::StatusCode.Unimplemented, ""));
      }

    }

    /// <summary>Creates service definition that can be registered with a server</summary>
    /// <param name="serviceImpl">An object implementing the server-side handling logic.</param>
    [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
    public static grpc::ServerServiceDefinition BindService(GreeterBase serviceImpl)
    {
      return grpc::ServerServiceDefinition.CreateBuilder()
          .AddMethod(__Method_SayHello, serviceImpl.SayHello).Build();
    }

    /// <summary>Register service method with a service binder with or without implementation. Useful when customizing the service binding logic.
    /// Note: this method is part of an experimental API that can change or be removed without any prior notice.</summary>
    /// <param name="serviceBinder">Service methods will be bound by calling <c>AddMethod</c> on this object.</param>
    /// <param name="serviceImpl">An object implementing the server-side handling logic.</param>
    [global::System.CodeDom.Compiler.GeneratedCode("grpc_csharp_plugin", null)]
    public static void BindService(grpc::ServiceBinderBase serviceBinder, GreeterBase serviceImpl)
    {
      serviceBinder.AddMethod(__Method_SayHello, serviceImpl == null ? null : new grpc::UnaryServerMethod<global::GrpcTester.HelloRequest, global::GrpcTester.HelloReply>(serviceImpl.SayHello));
    }

  }
}
#endregion

We have two static methods for serializing and deserializing the messages (__Helper_SerializeMessage, __ Helper_DeserializeMessage) inside Greeter static class.

And we had an abstract partial class (GreeterBase) having a virtual method SayHello. Remember we had the following method in our GreeterService class (earlier in the post), which overwrites the SayHello method in the abstract class.

public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
    {
        return Task.FromResult(new HelloReply
        {
            Message = "Hello " + request.Name
        });
    }

Running the Grpc Service

Just like any other project in Visual Studio, just hit F5 or use dotnet run command.

Here is the output when running the gRPC service.

But, you won’t be able to test the gRPC service directly in a browser, you need a gRPC client to test it because the client should also support gRPC to make a request for the gRPC service.

If we try to hit one of those exposed endpoints, we’d see this.

Communication with gRPC endpoints must be made through a gRPC client. To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909

This is because the Program.cs is set up with the default route.

app.MapGet("/", () => "Communication with gRPC endpoints must be made through a gRPC client. To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909");

References

The post Exploring gRPC project in ASP.NET Core appeared first on Code Rethinked.

Run dotnet core projects without opening visual studio

Karthik Chintala — Mon, 10 Apr 2023 01:52:00 +0000

In this blog post, we’ll see how to run dotnet core projects without opening visual studio. We all know Visual Studio is a great IDE and most developers already have visual studio installed on their computers.

In the microservice world, if we have .net core as our backend and we will sometimes have to launch multiple instances of visual studio and run them.

I had this trouble running multiple instances of Visual Studio for our product, but the laptop suffers to perform well though it has 32 GB of memory as I’ve to keep other programs open (like SQL server, vs code, etc).

What if I say we can run the .net core applications without launching visual studio at all? Yes, we can do this with .NET CLI.

Prerequisites

To do this, you have to install .NET CLI, which is a command line interface for developing, building, running, and publishing .net apps.

.NET CLI comes with .NET SDK. Starting with .NET Core 3.1 SDK, the .NET CLI is baked into .NET Core SDK. So, install a .NET SDK to get it working.

Checking the dotnet version with CLI

Once you’ve installed .NET SDK, you can check the version of the dotnet installed SDK by running the following command

dotnet --info

Running the app with .NET CLI

Here is what dotnet run command can do for us

dotnet run [-a|--arch <ARCHITECTURE>] [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--launch-profile <NAME>] [--no-build]
    [--no-dependencies] [--no-launch-profile] [--no-restore]
    [--os <OS>] [--project <PATH>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-v|--verbosity <LEVEL>] [[--] [application arguments]]

dotnet run -h|--help

To launch the .net core app without the visual studio

launch your favorite terminal
navigate to the project folder
enter dotnet run in the terminal and press Enter.

This should build the project and run the app, you should see port numbers with http and https in the terminal. The output should look something like this

When F5 key is pressed, Visual Studio launches the URL in a browser window, but the dotnet run command does not launch the URL in any browser window. You have to do it manually.

If we don’t provide any arguments to the dotnet run command line just as we did, it will launch the application with the default profile. You can find profiles in properties\\launchSettings.json file.

The default profile is the one with the same project name in the launchSettings.json file. You can define as many profiles as you want. Here is my launchSettings.json file

{
  "$schema": "<https://json.schemastore.org/launchsettings.json>",
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "<http://localhost:50206>",
      "sslPort": 44364
    }
  },
  "profiles": {
    "dotnet_cli_test": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "launchUrl": "swagger",
      "applicationUrl": "<https://localhost:7136>;<http://localhost:5008>",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "swagger": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

Launching dotnet run with a different profile name

If you have multiple profiles configured in launchSettings.json file and want to run other profile other than the default one you can use the —launch-profile switch on the dotnet run command.

It should look something like this

dotnet run --launch-profile 'swagger'

Here is how the output looks.

This time the port numbers were assigned automatically because our swagger profile does not have any application url’s defined.

That’s it. This is how .NET CLI can run .NET Core applications in the command line without opening visual studio IDE.

Command Line programs take way less memory than a Visual Studio IDE.

That’s okay for running programs but how do I get the power of IDE?

Well, you can use text editors (Visual Studio Code, Atom) that has C# extensions. Once you’ve installed extensions in Visual Studio Code you get similar features that are in a visual studio like intellisense, running tests, debugging, navigating through files, etc.

Yes, Visual Studio Code may not replace Visual Studio’s capabilities as an IDE. But, I’ll say you can live with what you have in Visual Studio Code for normal editing stuff.

Conclusion

In this post, we have seen how to install .NET CLI and how to run a .NET Core project without opening visual studio by making use of the .NET CLI command dotnet run and we’ve seen how to run a project with a different profile other than the default.

.NET CLI is much more than just running your project.

The .NET CLI has several commands which are mostly used for building, deploying, and running applications.

References

.NET CLI

The post Run dotnet core projects without opening visual studio appeared first on Code Rethinked.

Programmatically evaluating policies in ASP.NET Core

Karthik Chintala — Sun, 02 Apr 2023 15:17:00 +0000

Programmatically evaluating policies is useful when we want to provide access or hide some data based on the user’s access to a policy.

In our previous posts, we’ve seen how we can create policy-based authorization and how to set up multiple authorizations in asp.net core.

In this post, we’ll see how to programmatically evaluate a policy in

Razor Pages
Controllers/API controllers

IAuthorizationService to evaluate policies

We have IAuthorizationService in ASP.NET Core which has methods that check policy-based permissions for a user.

The IAuthorizationService has several AuthorizeAsync methods all of them take the ClaimsPrincipal as a parameter.

Methods in the interface:

Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object? resource, IEnumerable<IAuthorizationRequirement> requirements);
Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object? resource, string policyName);

Extension methods on IAuthorizationService:

Task<AuthorizationResult> AuthorizeAsync(this IAuthorizationService service, ClaimsPrincipal user, object? resource, IAuthorizationRequirement requirement);
Task<AuthorizationResult> AuthorizeAsync(this IAuthorizationService service, ClaimsPrincipal user, object? resource, AuthorizationPolicy policy)
Task<AuthorizationResult> AuthorizeAsync(this IAuthorizationService service, ClaimsPrincipal user, AuthorizationPolicy policy)
Task<AuthorizationResult> AuthorizeAsync(this IAuthorizationService service, ClaimsPrincipal user, string policyName)

All the methods return AuthorizationResult. The AuthorizationResult class has Succeeded and Failure properties which can be checked to determine the outcome.

Programmatically evaluating policy in razor pages

We will use the AuthorizeAsync method in the IAuthorizationService to validate our policies.

Remember for our policy-based authorization post we included links to our premium and standard lounges only when the user is signed in.

@if (SignInManager.IsSignedIn(User))
{
    <li class="nav-item">
        <a class="nav-link text-dark special-link" asp-area="" asp-page="/PremiumLounge" style="background: yellow;">Premium Lounge</a>
    </li>
    <li class="nav-item">
        <a class="nav-link text-dark special-link-2" asp-area="" asp-page="/StandardLounge" >Standard Lounge</a>
    </li>
}

Now, let’s just get things tighter by showing the links to the users who have access to premium or standard lounge pages.

We have two separate policies already for Premium and Standard lounges. Let’s use them here.

First, we inject the IAuthorizationService into the razor page.

@using Microsoft.AspNetCore.Authorization
@inject IAuthorizationService AuthorizationService

And for the

@if (SignInManager.IsSignedIn(User))
{
    var isPremium = await AuthorizationService.AuthorizeAsync(User, "PremiumOnly");
    var isStandard = await AuthorizationService.AuthorizeAsync(User, "StandardOnly");
    if (@isPremium.Succeeded)
    {
        <li class="nav-item">
            <a class="nav-link text-dark special-link" asp-area="" asp-page="/PremiumLounge" style="background: yellow;">Premium Lounge</a>
        </li>
    }

    if (@isStandard.Succeeded)
    {
        <li class="nav-item">
            <a class="nav-link text-dark special-link-2" asp-area="" asp-page="/StandardLounge">Standard Lounge</a>
        </li>
    }
}

We check for our policy names here and if they are successful only then we will show the links on the page.

Here is what a standard user’s view looks like.

A standard user can now only see the Standard Lounge link.

Programmatically evaluating policy in action methods

After that razor page demo, you should’ve guessed by now, we inject IAuthorizationService in the controller and call the AuthorizeAsync method and check the succeeded property on the result.

Here is our new user access controller.

[Route("api/[controller]")]
[ApiController]
public class UserAccessController : ControllerBase
{
    private readonly IAuthorizationService _authorizationService;
    public UserAccessController(IAuthorizationService authorizationService)
    {
        _authorizationService = authorizationService;
    }

    [HttpGet]
    public async Task<ActionResult<(bool isPremium, bool isStandard)>> GetUserPermissionsAsync()
    {
        var isPremium = await _authorizationService.AuthorizeAsync(User, "PremiumOnly");
        var isStandard = await _authorizationService.AuthorizeAsync(User, "StandardOnly");

        return Ok(new Tuple<bool, bool>(isPremium.Succeeded, isStandard.Succeeded));
    }
}

Notice that we’ve to pass in the claims user to access the AuthorizeAsync method.

Here is the result for a standard user trying to invoke the API.

{"item1":false,"item2":true}

References:

The post Programmatically evaluating policies in ASP.NET Core appeared first on Code Rethinked.

Multiple authorization handlers for the same requirement in ASP.NET Core

Karthik Chintala — Sun, 26 Mar 2023 18:29:00 +0000

We saw how we could set up policy-based authorization in our previous article. In this article, we’ll focus on

Need for multiple handlers for the same requirement
How to setup multiple handlers for the same requirement (with demo)
What would happen if we call context.Fail in the authorization handler if the user does not have access
The execution order of multiple authorizations

We’ll use the same scenario as we used for our policy-based authorization: two lounges, one for premium users and one for standard users.

Let’s say we want to allow the trial/limited user to experience the standard and premium lounges (I know they are just images on our razor pages :P)

In this case, creating a new policy with both standard and premium access won’t help because we have to decorate the existing page model to have both the old policy and the new one. This adds an AND logic to the authorizations.

Let’s say we have added this to our code

[Authorize(Policy = "LimitedUser")]
[Authorize(Policy = "StandardOnly")]
public class StandardLoungeModel : PageModel
{
    public void OnGet()
    {
    }
}

The authorization handlers now will only allow access to the standard page model only if the user has both the LimitedUser and StandardOnly access.

Technically, here we need an OR logic to allow either limited users or standard users. This is where the multiple handlers for the same requirement come in.

Multiple handlers for the same requirements

To perform an OR-based evaluation, we will create multiple handlers for the same requirement so that we can bypass the user if the user has limited access. No need to create a new policy for the trial users.

Here is our original product access handler from our previous policy-based authorization post.

public class ProductAccessHandler : AuthorizationHandler<ProductAccessRequirement>
{
    private readonly IUserAccessRepository _userAccessRepository;
    public ProductAccessHandler(IUserAccessRepository userAccessRepository)
    {
        _userAccessRepository = userAccessRepository;
    }

    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, ProductAccessRequirement requirement)
    {
        var user = ClaimExtensions.GetClaim(context.User, "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", "nameidentifier");
        if (user == null) {
          context.Fail();
          return Task.CompletedTask;
        }

        var hasAccess = _userAccessRepository.HasAccess(user.Value, requirement.ProductIds, CancellationToken.None);
        if (hasAccess) context.Succeed(requirement);

        return Task.CompletedTask;
    }
}

We will pass the user GUID and product Ids to the user access repository to see if the user has access to the resource. For more on how we set up the policy-based authorization please check this blog post.

Now, Let’s create a new TemporaryProductAccessHandler.

public class TemporaryProductAccessHandler : AuthorizationHandler<ProductAccessRequirement>
{
    private readonly IUserAccessRepository _userAccessRepository;

    public TemporaryProductAccessHandler(IUserAccessRepository userAccessRepository)
    {
        _userAccessRepository = userAccessRepository;
    }
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, ProductAccessRequirement requirement)
    {
        var user = ClaimExtensions.GetClaim(context.User, "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", "nameidentifier");
        if (user == null) {
          context.Fail();
          return Task.CompletedTask;
        }

        var hasAccess = _userAccessRepository.HasAccess(user.Value, new string[]{ Constants.ProductCodes.LimitedUser }, CancellationToken.None);

        if (hasAccess)
            context.Succeed(requirement);

        return Task.CompletedTask;
    }
}

There’s a small difference between the product access handler and the temporary product access handler.

In our TemporaryProductAccessHandler, we will always pass in the LimitedUser as the product id to the HasAccess method instead of passing the product ids we get from the requirement so that the current user is evaluated against the limited user product access.

If the user has limited user as the product access, then we will invoke context.Succeed(requirement) to pass through the product access handler and the user should have access to the resource requested.

If an action method or a razor page model has decorated with Authorize(Policy = "PremiumOnly")] and the user just has limited access as product ID, the product access handler does not produce any success result but the TemporaryProductAccessHandler will check for limited user access and passes the authorization test.

This is how we can bypass the user having limited user access and provide access to all of the resources.

Registering our handler for the same requirement

Registering is the same as how we register any service with its appropriate interface.

builder.Services.AddSingleton<IAuthorizationHandler, ProductAccessHandler>();
builder.Services.AddSingleton<IAuthorizationHandler, TemporaryProductAccessHandler>();

Once we registered our new TemporaryProductAccessHandler, we can simply run the app to see if the limited/temporary user is able to access the other pages. We don’t need to create new policies or add more Authorize attributes to the existing controllers or actions or razor page models.

Here is the demo of Limited user accessing both lounges

Limited users can access resources after multiple authorizations

If we invoked context.Fail() when a user does not have a product ID, what would happen?

Notice in our authorization handlers, we never called context.Fail() method though the user does not have access. We could do something like this in our ProductAccessHandler

var hasAccess = _userAccessRepository.HasAccess(user.Value, requirement.ProductIds, CancellationToken.None);

if (hasAccess)
    context.Succeed(requirement);
else 
    context.Fail();

f we implement an ProductAccessHandler like this, we can’t bypass the temporary user access restriction because we’re configuring the authorization to deny access if the user fails the product access test.

When any of the authorization handlers fail, access will be denied. But for authorization to succeed, at least one authorization handler must evaluate success.

We had the following code in our authorization handlers.

if (user == null) {
    context.Fail();
    return Task.CompletedTask;
}

If we encountered a null value for the user object we know the user is not logged in yet so we fail the authorization test.

But, in multiple authorizations, it’s better to ignore invoking context.Fail() when the user did not pass the authorization test because there could be another authorization handler that may check for attributes that could pass the authorization test.

Execution order of multiple authorization handlers

Although, Microsoft documentation claims that the handlers can execute in any order.

After debugging, I see the execution order of these handlers follows their order of registration in the Program.cs file.

So, if we registered TemporaryProductAccessHandler first and followed by ProductAccessHandler, the temporary handler gets fired first and product access gets the next hit.

builder.Services.AddSingleton<IAuthorizationHandler, ProductAccessHandler>();
builder.Services.AddSingleton<IAuthorizationHandler, TemporaryProductAccessHandler>();

Here is the debugging demo of the execution order.

Anyway, we are not worried about the order of execution in our article.

References

The post Multiple authorization handlers for the same requirement in ASP.NET Core appeared first on Code Rethinked.

Policy-Based Authorization in ASP.NET Core

Karthik Chintala — Sun, 19 Mar 2023 11:30:00 +0000

What is a policy-based authorization?

Unlike role-based authorization, which solely depends on the roles assigned to the users. A policy-based authorization uses requirements that will provide access to a resource when succeeded.

A requirement is a collection of data used to evaluate the current user.

Why do we need policy-based authorization?

With policy-based authorization, we have custom logic to provide access to a resource by configuring the policy-based authorization.

Composing a policy for policy-based authorization

To create a policy-based authorization we need 2 things:

A Policy Requirement: It is a collection of parameters that a policy can use when evaluating access to the user.
A Policy Handler: This is responsible for evaluating against the given requirements and determining if access is allowed.

Let’s say we have two pages on our website which represent two products. So, we will create two policies and the users who have access to the products will gain access to the resource.

Let’s create ProductAccessRequirement and ProductAccessHandler classes.

public class ProductAccessRequirement : IAuthorizationRequirement
{
    public string[] ProductIds { get; set; }

    public ProductAccessRequirement(string[] productIds)
    {
        ProductIds = productIds;
    }
}

Our ProductAccessRequirement will accept a list of product ids as the requirements.

Notice we have implemented the IAuthorizationRequirement interface for our requirement class. You will understand why we did it later in the article.

These will be configured in the Startup.cs or Program.cs (for .net 6+ programs) and will be utilized in the handler.

Here is our handler.

public class ProductAccessHandler : AuthorizationHandler<ProductAccessRequirement>
{
    private readonly IUserAccessRepository _userAccessRepository;
    public ProductAccessHandler(IUserAccessRepository userAccessRepository)
    {
        _userAccessRepository = userAccessRepository;
    }

    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, ProductAccessRequirement requirement)
    {
        var user = ClaimExtensions.GetClaim(context.User, "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", "nameidentifier");
        if (user == null) {
          context.Fail();
          return Task.CompletedTask;
        }

        var hasAccess = _userAccessRepository.HasAccess(user.Value, requirement.ProductIds, CancellationToken.None);
        if (hasAccess) context.Succeed(requirement);

        return Task.CompletedTask;
    }
}

Notice how we inherit from AuthorizationHanlder abstract generic class and pass in our ProductAccessRequirement as a type parameter.

We have to override the HandleRequirementAsync method, which is executed when we declare our endpoints to have policy-based authorizations.

Look at how we are setting the context.Fail() call when the user is null and the success call by invoking context.Succeed() when the user has access to the product ids.

Why do we care when the user object is null?

Well, authorization and authentication are two different things. The authorization handlers are still invoked even if the user is not authenticated.

We don’t have to explicitly specify context.Fail() instead we could just return a completed task (Task.CompletedTask), which is treated as a failure if there are no context.Succeed calls after executing the handler.

When should we call `context.Fail()` in authorization handlers?

First things first, a requirement can have multiple handlers defined and registered.

When all the handlers for a requirement are executed and if we want to fail the authorization when the requirements are not satisfied in any of the handlers then invoking context.Fail() this will force the failure even though the other handlers succeeded.

And we have a user repository, which will check whether the user has access to the product ids or not. For the user-to-product access map, I’ve created a dictionary with user ids and their respective product ids.

Here is our user access repository class.

public class UserAccessRepository : IUserAccessRepository
{
    private readonly Dictionary<string, string[]> userIdToProductAccessMap = new Dictionary<string, string[]>()
    {
        { "2a3aa5e6-071d-4d40-8cf9-5f986c8e5ded", new string[] { Constants.ProductCodes.StandardUser, Constants.ProductCodes.PremiumUser } },
        { "509bac4d-0648-4131-b0f5-52ce03a4069d", new string[] { Constants.ProductCodes.LimitedUser } },
        { "6bdeb8ac-2eb4-4cc1-a3ab-ed848a6967a9", new string[] { Constants.ProductCodes.StandardUser } },
        { "fc764407-c2d7-46b2-8652-9f7eb71dd5af", new string[] { Constants.ProductCodes.StandardUser, Constants.ProductCodes.PremiumUser } }
    };

    public bool HasAccess(string userId, string[] products, CancellationToken cancellationToken)
    {
        var userExistsInList = userIdToProductAccessMap.TryGetValue(userId, out var userProductIds);
        if (!userExistsInList || userProductIds?.Any() == false) return false;

        return products.All(p => userProductIds.Contains(p));
    }
}

If we used a real database connection to fetch the user-related product ids, then the authorization will become slow as we’d have to fetch from the database for every user. I’d recommend using some caching system such as redis or Memcached to have those values without having much latency.

Adding authorization in Program.cs

Now, let’s wire things up in the Program.cs file (.NET 6 and later versions) or in Startup.cs file (< .NET 6).

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("PremiumOnly", policy => policy.AddRequirements(new ProductAccessRequirement(new string[]
    {
        Constants.ProductCodes.PremiumUser
    })));

    options.AddPolicy("StandardOnly", policy => policy.AddRequirements(new ProductAccessRequirement(new string[]
    {
        Constants.ProductCodes.StandardUser
    })));

    options.AddPolicy("PremiumAndStandard", policy => policy.AddRequirements(new ProductAccessRequirement(new string[]
    {
        Constants.ProductCodes.StandardUser,
        Constants.ProductCodes.PremiumUser
    })));
});

We have defined 3 different policies and here is what they all mean.

PremiumOnly: We added the PremiumUser product code as a requirement to the policy. This allows only users who have PremiumUser product ID.
StandardOnly: We added the standard user product code as a requirement to the policy. This allows only users who have StandardUser product ID.
PremiumAndStandard: This access policy allows users to have premium user AND standard user access. The AND condition is because the HasAccess method defined in the user access repository will return true only if all the product IDs match in the requirements match with the user product IDs.

Here is how the policies are created in the authorization options.

options.AddPolicy("PremiumOnly", policy => policy.AddRequirements(new ProductAccessRequirement(new string[]
{
    Constants.ProductCodes.PremiumUser
})));

The AddPolicy method has two overloads. We used the one that takes the following 2 parameters

Name of the policy
An action delegate of type Action<AuthorizationPolicyBuilder>

We add requirements by calling the .AddRequirements on the policy and passing our ProductAccessRequirement as an argument.

The AddRequirements method accepts the instances of type IAuthorizationRequirement. This is why we have implemented our ProductAccessRequirement from IAuthorizationRequirement interface though the interface has nothing to be implemented.

Now, all we have to do is add these policies to the authorize attributes. Ex: [Authorize(Policy = "PremiumOnly")]

Defining the policies on the controllers or razor pages

Applying policies is the same for controllers and razor pages except that you cannot apply the authorize attribute to the razor page handlers.

For the purpose of the article, I’ve created two razor pages. One for the premium user and the other for a standard user.

[Authorize(Policy = "PremiumOnly")]
public class PremiumLoungeModel : PageModel
{
    public void OnGet()
    {
    }
}

[Authorize(Policy = "StandardOnly")]
public class StandardLoungeModel : PageModel
{
    public void OnGet()
    {
    }
}

Here is what the lounge pages look when the user has access to them.

With premium lounge access

With Standard Lounge access

Within the _Layout.cshtml file, I’ve included the links to these lounges like this to show these only if the user is signed in.

@if (SignInManager.IsSignedIn(User))
{
    <li class="nav-item">
        <a class="nav-link text-dark special-link" asp-area="" asp-page="/PremiumLounge" style="background: yellow;">Premium Lounge</a>
    </li>
    <li class="nav-item">
        <a class="nav-link text-dark special-link-2" asp-area="" asp-page="/StandardLounge" >Standard Lounge</a>
    </li>
}

For the purpose of this article, I’ve included the premium lounge link to the signed-in user as well so that everyone can see it but if they try to access the lounge they should get an access denied message.

Here is how the access denied error looks for both standard and premium lounge pages.

Access denied error

Let’s see how these policies work with a quick demo

policy-based authorization demo

References

The post Policy-Based Authorization in ASP.NET Core appeared first on Code Rethinked.

Role-based Authorization in ASP.NET Core

Karthik Chintala — Mon, 06 Mar 2023 02:01:16 +0000

What is role-based authorization?

As the name says, role-based authorization authorizes a user based on the role defined to the user.

Creating roles and users in ASP.NET Core with Identity

For this article, I’ve created a new ASP.NET Core app in .NET 6 with Individual Accounts as the Authentication type, which will create the roles, users, and other tables in the local database.

Here are the user and roles tables. I’ve added a few users and roles for our blog post.

roles and users

Configuring role-based authorization in `program.cs` or `startup.cs`

Let’s see how we can use the role-based authorization in the asp.net core web app.

In the Program.cs file, we have the following line indicating the default identity is added to the application (this is added to my project by default because I’ve created a brand new one with Individual Accounts)

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();

We will add .AddRoles<IdentityRole>() (The IdentityRole class is part of Microsoft.AspNetCore.Identity) to the line which then becomes this.

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

And we’ve to register useAuthorization() between UseRouting and UseEndpoints otherwise, we might run into the following issue.

Configure your application startup by adding app.UseAuthorization() in the application startup code. If there are calls to app.UseRouting() and app.UseEndpoints(…), the call to app.UseAuthorization() must go between them

Decorating controllers and Razor pages for Role-based authorization

Setting the Roles property on the Authorize attributes is how we set the role-based authorization.

Ex: [Authorize(Roles = "Admin")]

For controllers, we can decorate the controller class like this

[Authorize(Roles = "Admin")]
public class HomeController : Controller
{
  [Route("index")]
  public IActionResult Index()
  {
      return View();
  }
}

User having access invoking the Index action will see the below page

user having access to role

The user who does not have access to the Admin role receives the following access denied error.

user does not have access to role

Or we can have the Authorize on the action methods too.

[Authorize(Roles = "SuperUser")]
[Route("time")]
public IActionResult Time() => Content(new TimeOnly().ToLongTimeString());

The user having a superuser role sees the current time on the Time action.

user has access to superuser role

A user without a superuser role sees the following accessing the time action.

user has no access to superuser

That’s how we add role-based authorization to the controllers.

Similarly, we can add the authorizations to the razor page. But, we cannot add an Authorize attribute on the page handler methods.

Here is the warning if we tried to add the Authorize attribute on the page handler methods.

“MVC1001 ‘AuthorizeAttribute’ cannot be applied to Razor Page handler methods. It may be applied either to the Razor Page model or applied globally.”

Error when decorating authorize attribute over the Razor Page handler methods

How to apply multiple roles

To apply an OR between the roles to a single action we have to separate the roles by a comma

[Authorize(Roles = "SuperUser, Admin")]
public IActionResult Time() => Content(new TimeOnly().ToLongTimeString());

The time action is accessible to users who have either SuperUser or Admin roles

To apply an AND between the roles, we stack the Authorize attribute on the action/controller.

[Authorize(Roles = "SuperUser")]
[Authorize(Roles = "Admin")]
public IActionResult Time() => Content(new TimeOnly().ToLongTimeString());

Now, the time action is accessible only to the users who have both SuperUser and Admin as their roles.

Using policy-based roles

We can also combine multiple roles using policies and attach it to our controller/action/pages.

This has to be done in the Program.cs before we do the builder.Build() step

builder.Services.AddAuthorization(options => { 
  options.AddPolicy("SuperUserRights", policy => policy.RequireRole("Admin", "SuperUser", "BackupAdmin")); 
});

Applying this policy with [Authorize(Policy = "SuperUserRights")] should work for us.

[Authorize(Policy = "SuperUserRights")]
public IActionResult Time() => Content(new TimeOnly().ToLongTimeString());

References

Role-based authorization

The post Role-based Authorization in ASP.NET Core appeared first on Code Rethinked.

Contextual Feature Filters in ASP.NET Core

Karthik Chintala — Mon, 07 Nov 2022 01:40:10 +0000

While custom feature filters solve the problem of isolating the feature to a specific group or individual it may not be appropriate to rely on the HttpContext for every application we build.

For example, a console app will not have ambient HttpContext to check if the user has a specific email address that matches the email declared in the feature flag section.

For this purpose, we have Contextual Feature Filters in Microsoft.FeatureManagement package which take a context and evaluate the feature flag against a given context.

The contextual feature filters are declared and implemented similarly to custom feature filters.

Let’s see this in action.

IContextualFeatureFilter interface

public interface IContextualFeatureFilter<TContext> : Microsoft.FeatureManagement.IFeatureFilterMetadata

Contextual feature filters will only be executed if a context that is assignable from TContext is available.

Declaring contextual feature filter

Let’s create a contextual feature filter by implementing IContextualFeatureFilter interface.

public class AccountIdFilter : IContextualFeatureFilter<IAccountIdContext>
{
    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext featureFilterContext, IAccountIdContext appContext)
    {
        var settings = featureFilterContext.Parameters.Get<AccountIdSettings>();

        return Task.FromResult(settings.AccountId == appContext.AccountId);
    }
}

public interface IAccountIdContext
{
    string AccountId { get; set; }
}

public class AccountIdContext: IAccountIdContext
{
    public string AccountId { get; set; }

    public AccountIdContext(string accountId)
    {
        AccountId = accountId;
    }
}

public class AccountIdSettings
{
    public string AccountId { get; set; }
}

Instead of injecting the HttpContextAccessor to get the httpContext and get the account id or email to validate the feature flag, we get the AccountIdContext passed to the EvaluateAsync method.

We compare the app settings account id with the account id in the context. If they both match the feature flag is enabled, otherwise false.

Invoking IsEnabledAsync with context

Along with the feature flag name we also pass in the context to compare with.

if (await featureManager.IsEnabledAsync("SecretFeature", new AccountIdContext("123")))
{
    // do your something
}

appsettings.json configuration

The appsettings.json file should be similar to how we configure custom feature filters.

"FeatureManagement": {
    "SecretFeature": {
      "EnabledFor": [
        {
          "Name": "AccountId",
          "Parameters": {
            "AccountId": "d128f098-5a5b-4218-bb61-74305ecbdd32"
          }
        }
      ]
    }
  }

References

Contextual Feature Filters in Feature Management

The post Contextual Feature Filters in ASP.NET Core appeared first on Code Rethinked.

Tips for converting existing ASP.NET applications to ASP.NET Core

Karthik Chintala — Mon, 31 Oct 2022 02:26:41 +0000

The evolution of microservices greatly impacted how we think, write and manage applications in the cloud environment.

The existing monoliths are being migrated slowly to implement microservices and their patterns.

Scalability is one of the major aspects that developers/architects looking for migrating from ASP.NET Framework to ASP.NET Core.

I was reading the ASP.NET Core in Action, 3rd Edition, and found this chapter interesting on migrating existing asp.net applications to asp.net core. So, this blog post is about migrating.

Gist

In this post, we’ll see

Drawbacks of monolith applications
Challenges involved in converting ASP.NET Web Forms, MVC, and WCF to ASP.NET core applications
When to convert an application to ASP.NET Core

Drawbacks of a monolith application

Less scalable : Instead of scaling only the UI/API horizontally you may have to scale it vertically as it’s a monolith application
The codebase may become huge overtime
Deployment problems : Having to deploy a feature to larger codebases takes more time than deploying a small codebase.
Difficult to test : Adding a small feature to the project may affect the whole system. A full regression is required.
Tied to one technology : The choice of technology is limited to ASP.NET. If a problem can be solved easily with other technologies, with the asp.net framework or any monolith application you cannot do it

But, there are benefits of asp.net core that come along with migrating existing asp.net applications such as

Cross-platform deployment
Modularity
Performance

However, converting the existing asp.net applications may involve additional cost and technical expertise to do that transition.

There are difficulties converting the following applications to asp.net core

ASP.NET Web Forms
Is built using WCF
Is huge and uses advanced MVC features

Let’s see why it is difficult to transition the above use cases

Transitioning from ASP.NET Web Forms to ASP.NET Core

If the application is asp.net web forms, trying to convert it is not advisable as web forms are tied to System.Web.dll and IIS.

The conversion involves a complete rewrite of the app in ASP.NET Core.

It doesn’t mean your hopes of converting are dead at this point. There is a community-driven repository that guides on how to reuse much of the markup as in blazor.

Blazor server provides a component-based application that is similar to the web forms application model. So, you can convert web forms application gradually to asp.net core blazor application.

You can slowly transition the APIs into asp.net core web API application by reducing the reliance on the web forms concepts like ViewData.

ASP.NET Core In Action, Third edition

Transitioning from the WCF application

Windows Communication Foundation (WCF) is partially supported in ASP.NET Core. Again, it’s possible to build using the libraries for both the WCF client side (part of the .NET foundation) and the server-side (supported by the .Net foundation).

However, the above-mentioned libraries don’t support all of the APIs available in the .NET framework WCF. If you need all of them for sure, don’t migrate to ASP.NET Core for now.

Transitioning from MVC

If an MVC application is complex and uses the extensive features of MVC like message handlers, then porting to ASP.NET Core will be more difficult.

Although ASP.NET Core is built with similar features as MVC, the underlying architecture is different as ASP.NET Core is written from scratch.

ASP.NET Core in Action (save 45% now)

Andrew Lock teaches you how you can use your C# and .NET skills to build amazing cross-platform web applications.

Read Now

When to port an application to ASP.NET Core

If the existing application will need significant future development , then migrating to ASP.NET Core is a good choice.

If your application is rarely used and may not involve additional development efforts, then it’s better not to migrate to an ASP.NET Core application.

Microsoft will support .NET Framework for years to come (you may have to update the framework) though we have a new release of ASP.NET Core 7.

The best approach to migrating an ASP.NET core project is to start small and integrate with an existing application or start your new project as ASP.NET Core and integrate with an existing monolith.

It’s best to work in chunks rather than converting the entire application at once and Microsoft also provides YARP (a reverse proxy for .NET) and also ASP.NET Migration Tooling in Visual Studio to help implement the strangler fig pattern.

Pic Credits: Microsoft Learning

In the early migration, we see only a small portion of the modern application created in early migration and gradually most of the legacy system is migrated to the modern and then once the migration is complete we should have everything in the modern system.

Conclusion

ASP.NET Core applications offer modularity and performance at the same time. And they are best suited for microservices in the .NET ecosystem.

If your existing business is built on ASP.NET Framework and is working well and getting fruits for you then you don’t need to migrate to ASP.NET core.

Converting existing applications to asp.net core is possible but it involves planning, time, effort, and resources.

But, understanding the hard parts of the existing application is critical to transforming to an ASP.NET Core application. It helps to think about what it takes to convert the hard parts of the application first.

If you are creating a new product and the product really doesn’t need to be scalable for a huge number of users, you may not need to do it in ASP.NET Core. But, I’d recommend creating applications in ASP.NET Core now because .NET Framework may eventually retire sometime in the future and you may have to look up for ASP.NET Core again.

This article is sourced from a chapter in ASP.NET Core In Action, 3rd Edition written by Andrew Lock.

ASP.NET Core in Action (45% off)

This Andrew Lock’s revised bestseller reveals the latest .NET patterns, including minimal APIs and minimal hosting..

Read Now

Andrew lock also gives a great insight into how the ASP.NET Core works and how it processes a request and many great things we can do with ASP.NET Core. It’s worth a read.

References

The post Tips for converting existing ASP.NET applications to ASP.NET Core appeared first on Code Rethinked.

How to create a custom feature filter in ASP.NET Core

Karthik Chintala — Mon, 10 Oct 2022 07:56:15 +0000

While feature flags allow us to turn a feature on/off in real-time without any code changes. Feature filters go one level deep on the feature flags.

Feature filters allow us to filter/limit a feature to a specific group. This allows us to control who has access to the features.

Ex: We can limit the number of people who can see the feature or we can show the feature when the temperature is too hot. You can pretty much do like an if-this-then-that kind of thing with it.

There are three default feature filters available in ASP.NET Core. However, we can create custom feature filters.

In this post, we will see how to create a new custom feature filter with FeatureManagement package.

Takeaways

What are custom feature flags and uses.
By the end of this article, you should be able to create a custom feature filter and configure the necessary steps required to make it work.

Prerequisite

If you are unaware of what feature management or feature flags are you should first consider reading our comprehensive guide to feature management in asp.net core.

A prior understanding of feature management will make it easy to understand custom feature filters in asp.net core.

Use Case for custom feature filter

Let’s say we want to show a secret feature to only specific people in the organization.

For this article, I’ll create a new asp.net core application with asp.net core identity and create a couple of users. I’m not going to show you how to create users, asp.net core identity, or a new application as it is out of the scope of this article.

Quick Glance at Creating Custom Feature Filter

Before we dive in and write code to create a custom feature filter. Here is what we will be doing in this article.

Custom feature filter setup in appsettings.json file

Unlike the standard boolean feature flag which is set to either true/false, the custom feature flag is configured differently.

Here is how we configure our custom user feature filter

"FeatureManagement": {
    "SecretFeature": {
      "EnabledFor": [
        {
          "Name": "UserFeature",
          "Parameters": {
            "Email": ["karthik@coderethinked.com"]
          }
        }
      ]
    }
  }

Understanding EnabledFor section in Feature Management

Notice how the EnabledFor section is declared in the above appsettings.json file. We created an array of objects for EnabledFor property.

We can have multiple filters for the same feature flag item. If we declare multiple objects in the EnabledFor array they all would work like an OR filter for the feature flag.

Every object within the array of items in EnabledFor should have these two properties

Name : The name of our custom feature filter. The name should match any of the custom feature filters we create. In the above example, we declared the filter name as UserFeature. So, it looks for a feature filter class with the name “UserFeatureFilter” (Filter suffix is a convention here)
Parameters : This is where we set data for our filter. We can have multiple properties within the Parameters object and the properties can be of any type. In the example above, Email is an array of items. For accessing the parameter values, we can create a settings class and get a strongly typed object out of it.

Creating a feature filter class

Assuming you have prior knowledge of how to install the Microsoft.FeatureManagement package and setting it up a feature flag. If you don’t, please check this article.

Let’s create a custom feature filter for the user filter.

To create a custom filter we have to implement the IFeatureFilter interface in our UserFeatureFilter class.

The IFeatureFilter interface has EvaluateAsync method which has to be implemented and it returns a boolean. The result of the method serves as the value of the feature flag for the current request.

Here is our UserFeatureFilter class.

public class UserFeatureFilter : IFeatureFilter
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public UserFeatureFilter(IHttpContextAccessor accessor)
    {
        _httpContextAccessor = accessor;
    }

    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
    {
        var settings = context.Parameters.Get<UserFilterSettings>();
        var userIdentity = _httpContextAccessor.HttpContext?.User?.Identity;

        return Task.FromResult(settings.Email.Contains(userIdentity?.Name));
    }
}

And here is our UserFilterSettings class

public class UserFilterSettings
{
    public string[] Email { get; set; }
}

We are getting the parameters (Email) that are set for the filter in the appsettings.json file and we are matching the user identity name within the email array.

To know the user name from the HttpContext, we injected IHttpContextAccessor as a dependency to our filter class and the interface has to be registered in the startup.cs file.

IHttpContextAccessor should be used with caution. Our HttpContext on the IHttpContextAccessor instance may go null if there is no HttpContext.

Registering our custom feature flag in the startup.cs file

Let’s register our custom feature filter we created in the startup class and also the IHttpContextAccessor.

Within the ConfigureServices method, we register them like this:

services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>();
services.AddFeatureManagement().AddFeatureFilter<UserFeatureFilter>();

And that’s it!

Demo

https://i.imgur.com/wo5Bmii.mp4

That’s it! Thanks for reading.

References

The post How to create a custom feature filter in ASP.NET Core appeared first on Code Rethinked.

The Comprehensive Guide To Feature Management In ASP.NET Core

Karthik Chintala — Sun, 18 Sep 2022 23:30:00 +0000

Feature management in ASP.NET Core is released in 2019. Some of you may know about the feature flags and some may not even be heard of them.

In this post, we will see what is/are feature management or feature flags and how they are useful. And we will create a new feature to demonstrate the use of feature flags and we will also see the different ways we can access feature management in the code.

What is Feature management?
Why do we need feature flags?
Adding Feature Management package in ASP.NET Core
Configuring Feature management in ASP.NET Core app
Declaring Feature flags in appsettings.json
Consuming the feature flags in the ASP.NET Core Pages
Adding a feature
Toggle the feature flag on a feature
Why not check the feature flag in cshtml itself
- Injecting IFeatureManager in cshtml with @inject
- using the Feature Tag Helper to show or hide the feature flag
Summary
Infographic
References

What is Feature management?

Feature/feature flag management is the ability to show/hide a feature on demand.

Simply put, feature flags are like having a switch to control features which should either be shown or hidden to the user based on the flag value

A feature flag is also called a feature switch , feature toggle , feature gate , feature flipper, or conditional flipper.

Why do we need feature flags?

Assume that we have a brand new feature release for our product. But, the users are not aware of the feature and we’d want to show the feature somewhere on the product homepage and test them internally on production as well.

One way we could achieve this is to create a new sandbox environment and replicate the production data to the sandbox environment and test it.

That works! Now, let’s say we have a defect in the feature in production and it broke the whole thing. We’d have to redeploy the last best working version onto production.

What if I say that we can do it in real-time with just a flip of a flag? Yes, it’s feature flags that get the job done.

With feature flags, we can continuously develop the features and merge them to the main branch and deploy it to production. And in real-time we can show them or hide them based on the need.

These feature flags are more useful for product owners and testers who will test features in all environments.

Let’s dive in and understand feature management.

Adding Feature Management package in ASP.NET Core

Microsoft created a feature management package for ASP.NET Core.

As always you can install the package in a few different ways

Head over to the Nuget Package Manager in the Project context menu and search for Microsoft.FeatureManagement and install it
Or You can also install it with the Package Manager console in Visual Studio with this command Install-Package Microsoft.FeatureManagement -Version 2.5.1
Or you can also install it with .NET CLI dotnet add package Microsoft.FeatureManagement --version 2.5.1

Configuring Feature management in ASP.NET Core app

After installing the feature management package from NuGet, we have to add the feature management service in our ConfigureServices method in our startup class

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    services.AddFeatureManagement();
}

For the purpose of this article, I’ve created a new ASP.NET Core project. So, my ConfigureServices method has fewer services registered. You may have more services added to it. But, the order of adding feature management doesn’t matter.

Declaring Feature flags in appsettings.json

Now, let’s add the feature management section to the app settings file.

"FeatureManagement": {
    "CoolFeature": false,
    "SecretFeature": true
}

We declared our feature flags within FeatureManagement the section. The name of the section should be FeatureManagement as it is a convention.

If we give the section name other than FeatureManagement it won’t be picked by our IFeatureManager interface and we will get false as a value for all of our feature flags.

Every property within the FeatureManagement is a feature flag. In our configuration we have feature flags for CoolFeature and SecretFeature. We could also have filters within a feature (that’s a separate topic may be another article)

Setting true/false for a feature flag will return true/false when queried with IFeatureManager interface.

Consuming the feature flags in the ASP.NET Core Pages

Now we have our feature flags set up in appsettings.json file. Now, it’s time to query them to see if they are working.

Let’s head over to Index.cshtml.cs file and inject IFeatureManager into the IndexModel class.

Here is how the IndexModel.cs file looks like

public class IndexModel : PageModel
{
    private readonly ILogger<IndexModel> _logger;
    private readonly IFeatureManager _featureManager;

    public IndexModel(ILogger<IndexModel> logger, IFeatureManager featureManager)
    {
        _logger = logger;
        _featureManager = featureManager;
    }

    public async Task OnGet()
    {
        var secretFeature = await _featureManager.IsEnabledAsync("SecretFeature");
        _logger.LogInformation($"Secret Feature value: {secretFeature}");
    }
}

In the OnGet() method, we’ve logged our SecretFeature value. If we run the app and go to the Index page, we should see the log writing the flag value.

Fig 1: Feature flag value logged onto console

Adding a feature

Let’s add a secret feature to our home screen. So that when our SecretFeature is enabled we can see it on our index/home page.

So, let me create a partial view that holds the work done in that feature.

<div class="card" style="width: 400px; height: 400px;">
    <img src="https://images.unsplash.com/photo-1483706600674-e0c87d3fe85b?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=1507&q=80" class="card-img-top" alt="...">
    <div class="card-body">
        <h5 class="card-title">Secret Feature</h5>
        <p class="card-text">work in progress...</p>
    </div>
</div>

The code in our partial view is essentially a bootstrap card component with an image.

Here is what the card component looks like.

Fig 2: secret feature

Toggle the feature flag on a feature

we have to add conditional rendering in order to show this secret page only when SecretFlag is true.

Here is our Index.cshtml file

@page
@model IndexModel
@{
    ViewData["Title"] = "Home page";
}

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <p>Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core</a>.</p>
</div>

@if (Model.SecretFeatureEnabled)
{
    <partial name="_SecretPage" />
}

As you can see, based on the value of SecretFeatureEnabled we will show or hide our feature.

SecretFeatureEnabled is a property added to our IndexModel page which preserves the feature flag value

And here is our code behind file.

public class IndexModel : PageModel
{
    public bool SecretFeatureEnabled { get; set; }
    // ... other private variables and constructor

    public async Task OnGet()
    {
        SecretFeatureEnabled = await _featureManager.IsEnabledAsync("SecretFeature");
        _logger.LogInformation($"Secret Feature value: {SecretFeatureEnabled}");
    }
}

And we are done with our setup. Let’s run. Here is the demo

That’s it. We are able to toggle between true/false and able to see or hide our secret feature based on that.

Here is the source code on GitHub

Why not check the feature flag in cshtml itself

For the above demo, maybe I did too much to get the feature flag value from the code behind(IndexModel.cshtml.cs) to the cshtml file (IndexModel.cshtml).

We can also add the feature flag value to either ViewBag or ViewData and based on it we can render the partial view.

But, there are a few other ways to access the feature flag value directly in the cshtml file.

Injecting IFeatureManager in cshtml with @inject

Well, we can inject IFeatureManager into the view itself. Here is how it’s done.

@page
@inject Microsoft.FeatureManagement.IFeatureManager _featureManager;
@model IndexModel
@{
    ViewData["Title"] = "Home page";
}

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <p>Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core</a>.</p>
</div>

@if (await _featureManager.IsEnabledAsync("SecretFeature"))
{
    <partial name="_SecretPage" />
}

This may look crazy to you if you are new to this. But yes, ASP.NET Core supports dependency injection into views with @inject.

With this approach, we don’t need any changes to do in the Index.cshtml.cs file any more.(at least for this feature flag)

Here is the source code on Github

using the Feature Tag Helper to show or hide the feature flag

We can also use the feature tag helper in ASP.NET Core to do the same thing.

<feature name="@FeatureFlags.SecretFeature">
    <partial name="_SecretPage" />
</feature>

In order for this to work, we have to install Microsoft.FeatureManagement.AspNetCore package via NuGet and add it in _ViewImports.cshtml file like this.

@addTagHelper *, Microsoft.FeatureManagement.AspNetCore

We can also negate the feature flag value with negate attribute on the <feature> tag helper.

<feature name="@FeatureFlags.SecretFeature" negate="true">
 Feature will be shown if SecretFeature is disabled
</feature>

We can also use <feature> tag helper to show if all or any of the feature flags are enabled

<feature name="SecretFeature, CoolFeature" requirement="All">
    <p>This can only be seen if 'SecretFeature' and 'CoolFeature' are enabled.</p>
</feature>
<feature name="SecretFeature, FeatureB" requirement="Any">
    <p>This can be seen if 'SecretFeature', 'CoolFeature', or both are enabled.</p>
</feature>

And the source code of the feature flag with feature tag helper on Github

Summary

We saw what is feature management and why we need it
We created a secret feature that is behind a feature flag
We configured our feature flags in appsettings.json and saw how to access the feature flag value with IFeatureManager interface in csharp code
And learned different ways we can directly access the feature flag value in the razor template.

Infographic

The below infographic is just to give a glimpse of what feature management in asp.net core is. If you like this, please feel free to share this across your network.

References

Secret image from unsplash.com by Kristina Flour
Feature Management
Light switch animation from Pablo Danielli
Complete source code of this article on GitHub

The post The Comprehensive Guide To Feature Management In ASP.NET Core appeared first on Code Rethinked.

What are Minimal APIs in ASP.NET Core 6

Karthik Chintala — Mon, 29 Aug 2022 07:42:10 +0000

What is a Minimal API?

The goal of Minimal APIs in ASP.NET Core is to create HTTP API’s with minimum dependencies.

In the world of microservices, the backend API’s are becoming way too smaller and easier to work with. The minimal API’s may come in handy when working with small API’s which has only a few dependencies.

How to create Minimal API’s?

We can create minimal API’s either with Visual Studio 2022 or dotnet CLI.

With dotnet CLI

dotnet new webapi -minimal -o TodoApi
cd TodoApi
code -r ../TodoApi

With Visual Studio 2022

I’m not writing a step-by-step guide on how to create minimal APIs on visual studio 2022 as Microsoft documentation has those steps already.

But, an important step when creating ASP.NET Core Web API is to select .NET 6 framework and uncheck the "Use controller (uncheck to use minimal APIs)" option in the Additional information dialog.

Figure 1: setup minimal API’s in Visual Studio 2022

Notice we also have an option not to use the top-level statements checkbox here. If we check the "Do not use top-level statements" checkbox, we will have the usual Program.cs file with Main method in it instead of top-level statements.

Once we create a minimal API, we will have the default weather app which generates 5 random weather numbers for us.

Here is what the Program.cs file looks like with minimal API.

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weatherforecast", () =>
{
    var forecast = Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateTime.Now.AddDays(index),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
})
.WithName("GetWeatherForecast");

app.Run();

internal record WeatherForecast(DateTime Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

Within the Program.cs file, we see swagger is added to services, and swagger UI is also added to the request pipeline.

We can run and see if we want.

Where are `ConfigureServices()` and `Configure()` methods?

If you are not aware of these methods. The ConfigureServices() and Configure() methods are called by the ASP.NET Core runtime when the app starts. But, with minimal API’s these methods are removed and we can write our dependencies/middleware directly in the Program.cs.

If you want to register any services to the container then you’ve to add them after the builder is created with CreateBuilder(args) method but should not be after the builder.Build(). Assume that this is our old ConfigureServices method.

And if you want to add anything to the request pipeline like our old Configure method, you’ve to configure them with after builder.Build() but before app.Run(). Assume that this is our old Configure method.

Figure 2: Depicting the ConfigureServices and Configure methods in Program.cs

Ok, where is the main entry point?

The Program.cs file now does not have any Main method. This is because of the new language feature introduced as part of C# 9: Top-Level statements (we could configure the minimal APIs to generate the Main method by checking the Do not use top-level statements checkbox mentioned in Figure 1).

Behind the scenes, the compiler will inject the code you wrote in Program.cs into the main method for us.

Here is the Intermediate Language (IL) generated for Program.cs file in ILDASM

Intermediate Language showing the Main method in Minimal API

Setting up Repository for minimal API

Before we write minimal API’s let’s build a User repository.

public interface IUserRepository
{
    User GetUser(int id);
    bool UpdateUser(int id, User user);
    void DeleteUser(int id);
}

public class UserRepository : IUserRepository
{
    private List<User> _users = new List<User>();

    public UserRepository()
    {
        GenerateSeedData();
    }

    public User GetUser(int id)
    {
        return _users.FirstOrDefault(u => u.Id == id);
    }

    public bool UpdateUser(int id, User user)
    {
        var dbUser = _users.FirstOrDefault(u => u.Id == id);
        if (dbUser is null) return false;

        dbUser.UserName = user.UserName;
        dbUser.FirstName = user.FirstName;
        dbUser.LastName = user.LastName;

        return true;
    }

    public void DeleteUser(int id)
    {
        var user = _users.FirstOrDefault(u => u.Id == id);
        if (user is null) return;

        _users.Remove(user);
    }

    private void GenerateSeedData()
    {
        _users = new Faker<User>()
            .StrictMode(true)
            .RuleFor(u => u.Id, f => f.IndexFaker)
            .RuleFor(u => u.UserName, f => f.Person.UserName)
            .RuleFor(u => u.FirstName, f => f.Person.FirstName)
            .RuleFor(u => u.LastName, f => f.Person.LastName)
            .Generate(50);
    }
}

Our user repository has 3 basic operations

We can get a user by their Id
Update the user’s first name, last name, and also user name
Delete a user by Id

With the Faker class, we generated seed data for our repository. Faker class is part of Bogus library and Bogus is a fake data generator for C#. If you need more information about Bogus and how to generate fake data, take a look at this article.

Writing a minimal API

Now, let’s write our minimal API’s for user operations. Ideally, we’d have managers to have some business logic and also call the repositories. But, for this article let’s wire the repository directly to the APIs.

app.MapGet("/user/{id}", (int id, IUserRepository userRepository) =>
{
    var user = userRepository.GetUser(id);
    if (user is null) return Results.BadRequest();

    return Results.Ok(user);
}).WithName("GetUsers");

app.MapPut("/user/update/{id}", (int id, User user, IUserRepository userRepository) =>
{
    return userRepository.UpdateUser(id, user);
}).WithName("UpdateUsers");

app.MapDelete("/user/{id}", (int id, IUserRepository userRepository) =>
{
    userRepository.DeleteUser(id);
    return Results.Ok();
}).WithName("DeleteUser");

We have different extension methods for GET (MapGet), POST (MapPost), PUT (MapPut), DELETE (MapDelete) HTTP verbs. All these extension methods take the URL as the first argument and a Delegate as a second parameter. These methods are like our action methods in the MVC world.

Notice we are adding the IUserRepository to every endpoint here. The IUserRepository will be resolved with dependency injection as one would expect.

We also see Results.Ok(), Results.BadRequest() methods in our API’s. Results is a static helper class that exits in Microsoft.AspNetCore.Http namespace which provides basic return types for API’s. Here is the list of built-in results in the Results class.

At the end of the API, we have .WithName method which is optional here. The argument you provide here will be operationId in the swagger.json file for each of the operations.

Now, Let’s run and see how they all work.

Demo: Minimal API demo

Full Program.cs code

Here’s the Program.cs file after adding our user endpoints.

using MinimalAPIs.Repositories;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();

// Add services to the container.
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

builder.Services.AddSingleton<IUserRepository, UserRepository>();

var app = builder.Build();
app.MapControllers();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.MapGet("/user/{id}", (int id, IUserRepository userRepository) =>
{
    var user = userRepository.GetUser(id);
    if (user is null) return Results.BadRequest();

    return Results.Ok(user);
}).WithName("GetUsers");

app.MapPut("/user/update/{id}", (int id, User user, IUserRepository userRepository) =>
{
    return userRepository.UpdateUser(id, user);
}).WithName("UpdateUsers");

app.MapDelete("/user/{id}", (int id, IUserRepository userRepository) =>
{
    userRepository.DeleteUser(id);
    return Results.Ok();
}).WithName("DeleteUser");

app.Run();

Limitations of Minimal API’s

Minimal APIs also has few limitations.

No support for filters. Yes, we cannot use exception filters, result filters, action filters etc
No built-in support for validation (IModelValidator). If you’ve been using ModelState.IsValid on your controller actions then it won’t work with Minimal API’s. You have to write your own validators to validate the input.
No support for OData, JsonPatch, ApiVersioning

When to use Minimal API’s?

As you can see in this post, we’ve come far from the MVC mindset here. We don’t see any controllers or action methods that typically create our endpoints in the Web API’s.

If you are starting with a brand new microservice that is fairly small, then it’s better to start with minimal API.

But, if you think your backend is going to have more endpoints in the future like an enterprise backend then using controllers might be a better choice.

References

The post What are Minimal APIs in ASP.NET Core 6 appeared first on Code Rethinked.

Strongly Typed Configurations with Options Pattern

Karthik Chintala — Mon, 29 Aug 2022 01:44:22 +0000

In this post, we’ll see how to read the configuration file using the options pattern. The options pattern is recommended to read the app configuration in ASP.NET Core.

Before we see how to make configurations strongly typed the options pattern, we’ll see how to read the configuration settings using the IConfiguration interface.

Reading Configuration settings with IConfiguration in ASP.NET Core

Let’s say we have the following configuration in our appsettings.json file

{
  "Pattern": {
    "Name": "Options Pattern",
    "Version": 1
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }
}

And here’s how you read it

public class PrintOptionsController : ControllerBase
{
    private IConfiguration _configuration;

    public PrintOptionsController(IConfiguration configuration)
    {
        _configuration = configuration;
    }

    [HttpGet]
    public List<string> GetOptions()
    {
        var options = new List<string>();

        options.Add(_configuration["Pattern:Name"]);
        options.Add(_configuration["Pattern:Version"]);
        options.Add(_configuration["Logging:LogLevel:Default"]);

        return options;
    }
}

To read nested options, we’ve to use a colon (:) as a separator between the nested properties. Ex: Pattern:Name, Pattern:Version

If we run this, we should see this as the result

["Options Pattern","1","Information"]

This is working fine.

But, there’s a problem here. Every configuration value is a string no matter how you declare it in the appsettings.json file.

And we’ve to hard code or store the configuration keys somewhere in the constants file so that we don’t have to hardcode it every time we use it.

This is not great because we have to manually parse the configuration values to the appropriate type every time.

So, the preferred way to read configuration is to use strongly typed classes with Options pattern.

What is the Options pattern?

The options pattern uses classes to provide strongly typed access to groups of related settings.

From Microsoft

The Options pattern adheres to the following software principles:

Encapsulation or Interface Segregation Principle (ISP): Classes that depend on configuration settings rely only on the configuration settings that they use.
_ Separation of Concerns _: As each class is tied to different settings in the configuration file they aren’t dependent or coupled.

Rules for Options class to work

Our options class should be

Non-abstract and should have a public parameterless constructor
All public read-write properties of the type are bound

Reading appsettings.json with Options pattern

The properties in our Options class should correspond to what we have in our appsettings.json file. We had the following JSON in our appsettings.json file which we wanted to be strongly typed.

"Pattern": {
    "Name": "Options Pattern",
    "Version": 1
  }

So, our PatternOptions class should have two properties. Name and Version.

public class PatternOptions
{
    public const string SectionName = "Pattern";

    public string Name { get; set; }
    public int Version { get; set; }
}

We had the constant SectionName, which is not bound to the configurations. This is just to avoid hardcoding while configuring options pattern in the startup class.

Now, let’s configure our PatternOptions in the startup class.

In our ConfigureServices method in the startup class, add the following line

services.Configure<PatternOptions>(Configuration.GetSection(PatternOptions.SectionName));

That’s it! Our PatternOptions class is now good to go. We can inject our class anywhere and read the configurations.

Injecting our PatternOptions class with IOptions interface

Instead of reading the configuration from IConfiguration interface we will now read from IOptions<T>. The T is our PatternOptions.

So, let’s remove the IConfiguration injection from our PrintOptionsController and inject IOptions with PatternOptions as a type.

public class PrintOptionsController : ControllerBase
{
    private PatternOptions _patternOptions;

    public PrintOptionsController(IOptions<PatternOptions> options)
    {
        _patternOptions = options?.Value;
    }

    [HttpGet("withOptionsPattern")]
    public PatternOptions GetOptionsWithIOptions()
    {
        return _patternOptions;
    }
}

Within the constructor, we have assigned options?.Value to _patternOptions variable. Or we could only get the .Value only in the action method we need.

If we run the app, we should get our options from the configuration file.

{"name":"Options Pattern","version":5}

What are Named options?

Named options are used when we have multiple sections that bind to the same properties.

Let’s say we have the following in our appsettings.json file

"Seasons": {
    "Winter": {
      "Month": "December", 
      "Temperature": 25
    },
    "Summer": {
      "Month": "April", 
      "Temperature": 45
    },
    "Monsoon": {
      "Month": "July",
      "Temperature": 35
    } 
  }

Now, if we’ve to make options pattern out of this, we’d have to create 3 different classes (1 for winter, 1 for summer, and the other for monsoon) and bind these in the section configuration in the startup class.

But, with Named options, we can have the following class and use it for all seasons.

public class SeasonsOptions
{
    public const string Winter = "Winter";
    public const string Summer = "Summer";
    public const string Monsoon = "Monsoon";

    public string Month { get; set; }
    public int Temperature { get; set; }
}

Notice we have the common properties for all 3 seasons (Month and Temperature) and we have the constant variables for season names (these are not bound to the configuration as said earlier we’ll use them for configuration).

And in the startup, we can register the sections individually using the same SeasonsOptions class.

services.Configure<SeasonsOptions>(SeasonsOptions.Winter, Configuration.GetSection("Seasons:Winter"));
services.Configure<SeasonsOptions>(SeasonsOptions.Summer, Configuration.GetSection("Seasons:Summer"));
services.Configure<SeasonsOptions>(SeasonsOptions.Monsoon, Configuration.GetSection("Seasons:Monsoon"));

Once we are done with the setup we can modify our print options controller to be something like this

public class PrintOptionsController : ControllerBase
{
    private SeasonsOptions _winterSeasonOptions;
    private SeasonsOptions _summerSeasonOptions;
    private SeasonsOptions _monsoonSeasonOptions;

    public PrintOptionsController(IOptionsSnapshot<SeasonsOptions> namedWinterOptions)
    {

        _winterSeasonOptions = namedWinterOptions.Get(SeasonsOptions.Winter);
        _summerSeasonOptions = namedWinterOptions.Get(SeasonsOptions.Summer);
        _monsoonSeasonOptions = namedWinterOptions.Get(SeasonsOptions.Monsoon);
    }

    [HttpGet("getSeasonOptions")]
    public List<SeasonsOptions> GetAllSeasons()
    {
        return new List<SeasonsOptions>
        {
            _winterSeasonOptions,
            _summerSeasonOptions,
            _monsoonSeasonOptions
        };
    }
}

Notice we are using IOptionsSnapshot instead of IOptions here. This is because the IOptions interface does not support Named options.

IOptionsSnapshot interface is generally used when options should be recomputed on every request. Yes, there’s a performance penalty with this as it is a scoped service and needs to be recomputed per request. So, use it with caution.

Now, if we run the app we should see all the seasons and their temperatures.

[{"month":"December","temperature":25},{"month":"April","temperature":45},{"month":"July","temperature":35}]

That’s it! Thanks for reading.

Please comment below and let me know your thoughts on the options pattern in ASP.NET Core.

References

The post Strongly Typed Configurations with Options Pattern appeared first on Code Rethinked.

Forem: Karthik Chintala

Exploring gRPC project in ASP.NET Core

Prerequisites

Creating a gRPC Server

Exploring newly created gRPC project

Where are the message types declared?

Understanding .proto file

Why do we need to assign a number to the fields on the message types?

What’s in our compiled C# files from .proto file?

Running the Grpc Service

References

Run dotnet core projects without opening visual studio

Prerequisites

Checking the dotnet version with CLI

Running the app with .NET CLI

Launching dotnet run with a different profile name

That’s okay for running programs but how do I get the power of IDE?

Conclusion

References

Programmatically evaluating policies in ASP.NET Core

IAuthorizationService to evaluate policies

Programmatically evaluating policy in razor pages

Programmatically evaluating policy in action methods

References:

Multiple authorization handlers for the same requirement in ASP.NET Core

Multiple handlers for the same requirements

Registering our handler for the same requirement

If we invoked context.Fail() when a user does not have a product ID, what would happen?

Execution order of multiple authorization handlers

References

Policy-Based Authorization in ASP.NET Core

What is a policy-based authorization?

Why do we need policy-based authorization?

Composing a policy for policy-based authorization

Why do we care when the user object is null?

When should we call context.Fail() in authorization handlers?

Adding authorization in Program.cs

Defining the policies on the controllers or razor pages

References

Role-based Authorization in ASP.NET Core

What is role-based authorization?

Creating roles and users in ASP.NET Core with Identity

Configuring role-based authorization in program.cs or startup.cs

Decorating controllers and Razor pages for Role-based authorization

How to apply multiple roles

Using policy-based roles

References

Contextual Feature Filters in ASP.NET Core

IContextualFeatureFilter interface

Declaring contextual feature filter

Invoking IsEnabledAsync with context

appsettings.json configuration

References

Tips for converting existing ASP.NET applications to ASP.NET Core

Gist

Drawbacks of a monolith application

Transitioning from ASP.NET Web Forms to ASP.NET Core

Transitioning from the WCF application

Transitioning from MVC

ASP.NET Core in Action (save 45% now)

When to port an application to ASP.NET Core

Conclusion

ASP.NET Core in Action (45% off)

References

How to create a custom feature filter in ASP.NET Core

Prerequisite

Use Case for custom feature filter

Quick Glance at Creating Custom Feature Filter

Custom feature filter setup in appsettings.json file

Understanding EnabledFor section in Feature Management

Creating a feature filter class

Registering our custom feature flag in the startup.cs file

Demo

References

The Comprehensive Guide To Feature Management In ASP.NET Core

Table Of Contents

What is Feature management?

Why do we need feature flags?

Adding Feature Management package in ASP.NET Core

Configuring Feature management in ASP.NET Core app

When should we call `context.Fail()` in authorization handlers?

Configuring role-based authorization in `program.cs` or `startup.cs`

Where are `ConfigureServices()` and `Configure()` methods?