DEV Community: Miiro Ashirafu

Using the new EF Core Provider For MongoDB with ASP.NET Core Identity

Miiro Ashirafu — Mon, 13 Jan 2025 12:14:03 +0000

In this guide, I will show you how to use the current version (8.2.1) of the EF Core Provider for mongoDB with its limitations.

The limitations that prevent this provider from directly being used for ASP.NET Core Identity include lack of support for the Select projection and some other Linq operations, which are used in Identity. Therefore some extra steps are needed to achieve an operational program.

Prerequisites

You need the following to complete follow along.

Mongo Atlas account and a database URL for your cluster
Configured development Environment that can develop Blazor Server App (I will be using Visual Studio 2022)
An active internet connection (I guess it's obvious but anyway)

Creating the project

In Visual studio, Create a Blazor Server application (I have named min WeatherApp) and choose .NET version to 8.0 LTS and Athentication type to Individual Account. For Interactive render mode, select Server and choose your Global Interactivity location

After creating the application, you will notice that it has been configured to use SQL server by Default as the storage for EF Core in the Program.cs file. We shall change this shortly

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection") ?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

Adding MongoDB related configurations

We shall start by installing the required nugget packages.
Use any preferred method to install the package MongoDB.EntityFrameworkCore version 8.2.
In the appsettings.json file define an object to store the MongoDB settings as shown below

  "MongoDBSettings": {
    "AtlasURI": "mongodb+srv://<username>:<password>@cluster0.abc.mongodb.net/?retryWrites=true&w=majority",
    "DatabaseName": "weatherapp"
  }

For the AtlasURI key, use the URI from the cluster that you created in your MongoDB Atlas account.
Also create a MongoDBSettings class in the Data folder in the root of the project to be used in mapping the settings.

 public class MongoDBSettings
 {
     public string AtlasURI { get; set; } = string.Empty;
     public string DatabaseName { get; set; } = string.Empty;
 }

In the Program.cs file, there is a section of code used to configure the database context to use SQL server as shown below.

Replace that code with the code below, that uses MongoDB provider.

builder.Services.Configure<MongoDBSettings>(
    builder.Configuration.GetSection("MongoDBSettings"));

var mongoDBSettings = builder.Configuration.GetSection("MongoDBSettings").Get<MongoDBSettings>();
builder.Services.AddDbContext<ApplicationDbContext>(options =>
            options.UseMongoDB(mongoDBSettings!.AtlasURI ?? "", mongoDBSettings.DatabaseName ?? "")
                .EnableSensitiveDataLogging());
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

Using the MongoDB `ObjectId` as the primary key type for ASP.NET Core Identity

By default, ASP.NET Core Identity uses a GUID string as the primary key while storing users in the SQL databases. However, it allows you to customize this and use another type like long, ulong, int, etc. In this case, since our databases uses its on unique identifier as the ObjectId, we shall use this for identity. Let do the necessary modifications to ensure this.

Note: Remember to add the necessary using statements in each file where we have modified the code.

Firstly, modify the ApplicationUser class in the Data folder to use the ObjectId as the primary key type for the identity user.

public class ApplicationUser : IdentityUser<ObjectId>
{
}

In the same Data folder, modify the ApplicationDbContext class to also inherit from a version of IdentityDbContext that allows specifying a different type for the primary key of the user and roles. We shall use ObjectId for both.

public class ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) 
        : IdentityDbContext<ApplicationUser, IdentityRole<ObjectId>, ObjectId>(options)
{
}

At this moment, we are able to run the application and a user can be registered. But when we try some other operations like the default account confirmation, we get exceptions notifying us that the conversion from the string type to the ObjectId type is not supported.

This prevents us from using other identity features. In order to handle this, and the other limitations of the EF Core Provider for MongoDB, we shall need to use a custom store for both users and roles.

Creating the custom stores for identity

In the project, create a new folder and name it CustomIdentityStores and create 2 files, namely UserStore.cs and RoleStore.cs

Get the starter code from the identity repository for each of these files using the links below (from the official identity repository)

Apart from the namespace declaration, paste the rest of the code into the corresponding file and we deal with the modifications (use local namespace).

In the UserStore.cs we shall have one error corresponding to some resource that we don't have access to.

For simplicity, just replace it to a constant string(e.g. "Role Not Found")

Modify the custom stores to handle Id conversion and other limitations of the provider

`UserStore.cs`

In this file, replace the FindByIdAsync method by the code below, which uses the ObjectId.Parse method instead of the identity one.

    public override Task<TUser?> FindByIdAsync(string userId, CancellationToken cancellationToken = default(CancellationToken))
    {
        cancellationToken.ThrowIfCancellationRequested();
        ThrowIfDisposed();
        var id = ObjectId.Parse(userId);// ConvertIdFromString(userId);
        return UsersSet.FindAsync(new object?[] { id }, cancellationToken).AsTask();
    }

Also modify the default User Store type and the corresponding other implementations to use ObjectId as the type of the unique identifier for both User and Role entities.
Make sure that you replace the DBContext injected in the default implementation to use the one ApplicationDbContext of our application.

In addition, methods such as GetRolesAsync where unsupported features such as the select projection are used, we can use client-side evaluation if we don't have a lot of roles or use any techniques of your choice to convert the Linq to SQL logic to something that is supported by the provider.
For example the code shown below:

can be converted to.

Do this for all such cases (e.g. in the GetClaimsAsync method) and end up with the changes as shown in the complete file here.

RoleStore.cs

In this file, follow the same steps as in the UserStore.cs. The example result is shown the completed file here.

Register the new Stores

In the Program.cs file, register these classes to be used by identity instead of the default stores by using the code below.

builder.Services.AddTransient<IUserStore<User>, UserStore>();
builder.Services.AddTransient<IRoleStore<IdentityRole<ObjectId>>, RoleStore<IdentityRole<ObjectId>>>();

Once Everything is wired correctly, You should be able to run the application, register, login and view the authorized resources.

Find the completed code in a git hub repository here.

Enjoy coding without any limits.

Using EDMX file and T4 in .NET Core to Generate Code (Entities, DTO, API, Services etc.)

Miiro Ashirafu — Wed, 04 May 2022 16:54:15 +0000

Hello there!
I am going to briefly show you how we can use existing EDMX files from EF 6 to generate code in .NET Core applications (migrate EF 6 to EF Core). This sample will be using T4 text Templates. I will share a link to the completed project at the end of the post.

From the docs:

Database First allows you to reverse engineer a model from an existing database. The model is stored in an EDMX file (.edmx extension) and can be viewed and edited in the Entity Framework Designer.

After getting our model from EF 6 project, we can add the .edmx file to the solution where we want to generate the code.

We then add the .tt file to a .NET core project (Class Library or Web API) at the location where the entities are to be generated.
In Visual Studio 2022, we shall need to adjust the T4 template code in order to have access to the VS host environment.

DataModel.tt



<#@ template language="C#" debug="false" hostspecific="true"#>
<#@ include file="EF6.Utility.CS.ttinclude"#>
<#@ output extension=".cs"#>
<#@ assembly name="Microsoft.VisualStudio.Interop" #>
<#@ import namespace="EnvDTE" #>

<#
IServiceProvider serviceProvider = (IServiceProvider)this.Host;
DTE dte = serviceProvider.GetService(typeof(DTE)) as DTE;

// path to the DataModel.edmx file 
string inputFile = Path.Combine(Path.GetDirectoryName(dte.Solution.FullName), "DataAccess", "DataModel", "DataModel.edmx");

var textTransform = DynamicTextTransformation.Create(this);
var code = new CodeGenerationTools(this);

...

After that, we shall have our entities in the same directory containing the .tt file.

Generating DTOs

DTOs are usually derived by eliminating Navigation properties from entities. They are a more portable version of the DB entities which can be used in data transfer. For our case, we shall also make all value type properties nullable to use them in updating our database.

To a location where you want to add the DTOs (project or folder), right click in the VS solution explorer to add an existing item
Browse to the location where the entities are and add the DataModel.tt file.
Rename the file to DTO.tt and then modify it to generate the DTOs.

Modifying the DTO.tt file

Firstly, we prevent the generation of the constructor in case there are collection navigation properties using the code below.



 if (false && (propertiesWithDefaultValues.Any() || collectionNavigationProperties.Any() || complexProperties.Any()))
    { ...

It can also be done by deleting the entire if statement.
Secondly, we eliminate the generation of navigation properties, either using the same technique or deleting the entire if statement.



 var navigationProperties = typeMapper.GetNavigationProperties(entity);
    if (navigationProperties.Any() && false) // && false will make it always false
    {

Lastly, we specify that all fields are nullable by modifying the following method in the TypeMapper class as follows:



public string GetTypeName(TypeUsage typeUsage)
    {
        // the second parameter is given a value true
        return typeUsage == null ? null : GetTypeName(typeUsage.EdmType, true, modelNamespace: null);
    }

With those modifications we have our DTOs generated as required

Employee.cs



 public partial class Employee
    {
        public int ID { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Gender { get; set; }
        public Nullable<int> Salary { get; set; }
        public Nullable<int> DepartmentId { get; set; }

        public virtual Department Department { get; set; }
    }

EmployeeDTO.cs



//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated from a template.
//
//     Manual changes to this file may cause unexpected behavior in your application.
//     Manual changes to this file will be overwritten if the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

namespace DataAccess.DTO
{
    using System;
    using System.Collections.Generic;

    public partial class EmployeeDTO
    {
        public Nullable<int> ID { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Gender { get; set; }
        public Nullable<int> Salary { get; set; }
        public Nullable<int> DepartmentId { get; set; }
    }
}

After that, we now create the Context manually and use it in our services in the next step.



 public partial class EmployeeContext : DbContext
    {
        public string DbPath { get; }
        public EmployeeContext(DbContextOptions<EmployeeContext> options)
            : base(options)
        {
            var folder = Environment.SpecialFolder.LocalApplicationData;
            var path = Environment.GetFolderPath(folder);
            DbPath = System.IO.Path.Join(path, "employees.db");
        }

        protected override void OnConfiguring(DbContextOptionsBuilder options)
        => options.UseSqlite($"Data Source={DbPath}");

        public virtual DbSet<AuditEntry> AuditEntries { get; set; }
        public virtual DbSet<Department> Departments { get; set; }
        public virtual DbSet<Employee> Employees { get; set; }
    }

Generating Services

For the services, we shall use a generic Repository just for demonstration. The code used is not the exact approach that is documented to describe the repository pattern.



public interface IRepository<T, TDTO>
    {
        T Add(T entity);
        T Update(TDTO entity);
        T Delete(T entity);
        T GetOne(int? id);
        List<T> GetAll();
    }

For further simplicity, we shall also add a default implementation to provide defaults for some methods.



public class BaseRepository<T, TDTO> : IDisposable, IRepository<T, TDTO> where T : class
    {
        private readonly DbSet<T> _table;
        private readonly EmployeeContext _context;
        protected readonly ILogger logger;

        public BaseRepository(EmployeeContext context, ILogger logger)
        {
            _context = context;
            this.logger = logger;
            _table = _context.Set<T>();
        }
        protected EmployeeContext Context => _context;

        public T Add(T entity)
        {
            _table.Add(entity);
            SaveChanges();
            return entity;
        }

        public T Delete(T entity)
        {
            _context.Entry(entity).State = EntityState.Deleted;
            SaveChanges();
            return entity;
        }

        public void Dispose()
        {
            _context?.Dispose();
        }

        public List<T> GetAll() => _table.ToList();

        public T GetOne(int? id)
        {
            return _table.Find(id);
        }

        public virtual T Update(TDTO entity)
        {
            throw new NotImplementedException();
        }

        internal void SaveChanges()
        {
            try
            {
                _context.SaveChanges();
            }
            catch (DbUpdateException e)
            {
                var sb = new StringBuilder();
                sb.AppendLine($"DbUpdateException error details - {e?.InnerException?.InnerException?.Message}");

                foreach (var eve in e.Entries)
                {
                    sb.AppendLine($"Entity of type {eve.Entity.GetType().Name} in state {eve.State} could not be updated");
                }
                logger.LogError(e, sb.ToString());
                throw;
            }
            catch (Exception ex)
            {
                logger.LogError(ex, ex.Message);
            }
        }
    }

In order to generate the services that we shall use in the generated API, we create the interfaces first.



  public partial interface IAuditEntryService : IRepository<AuditEntry, AuditEntryDTO>
    {

    }
public partial interface IDepartmentService : IRepository<Department, DepartmentDTO>
    {

    }
  public partial interface IEmployeeService : IRepository<Employee, EmployeeDTO>
    {

    }

The Services.tt file is added and modified to generate the Servies. The Update method is also implemented in the services and a snipped for this in the t4 template is shown below



 public override <#=code.Escape(entity)#> Update(<#=code.Escape(entity)#>DTO entity)
    {
        <#=code.Escape(entity)#> returnValue = null;

        try
        {
            var model = this.Context.<#=code.Escape(entity).Pluralize()#>.Where(p => p.<#=code.Escape(idProperty)#> == entity.<#=code.Escape(idProperty)#>).FirstOrDefault();


            if (model != null)
            {
            <#     

        if (simpleProperties.Any())
        {
            foreach (var edmProperty in simpleProperties)
            {#>

                if (entity.<#=code.Escape(edmProperty) #> != null)
                {
                    model.<#=code.Escape(edmProperty) #> = entity.<#=codeStringGenerator.PropertyAssign(edmProperty) #>;
                }
        <#
            }
        }#>

                this.Context.<#=code.Escape(entity).Pluralize()#>.Update(model);
                this.SaveChanges();

                // refresh entity
                returnValue = this.Context.<#=code.Escape(entity).Pluralize()#>.Where(p => p.<#=code.Escape(idProperty)#> == entity.<#=code.Escape(idProperty)#>).FirstOrDefault();;

            }

        }
        catch (Exception ex)
        {
            logger.LogError(ex, ex.Message);
        }

        return returnValue;
    }

In the services, Humanizer.Core is used to provide more control in the name naming of properties other class members.
The following code shows one of the services generated by the .tt file



//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated from a template.
//
//     Manual changes to this file may cause unexpected behavior in your application.
//     Manual changes to this file will be overwritten if the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

namespace DataAccess.Services
{
    using System;
    using System.Collections.Generic;

    using DataAccess.DTO;
    using DataAccess.Entities;
    using DataAccess.Repository;
    using DataAccess.Interfaces;
    using DataAccess.Context;
    using Microsoft.Extensions.Logging;

    public partial class EmployeeService : BaseRepository<Employee, EmployeeDTO>,  IEmployeeService
    {

        public EmployeeService(EmployeeContext context, ILogger<EmployeeService> logger): base(context, logger)
        {
        }

        public override Employee Update(EmployeeDTO entity)
        {
            Employee returnValue = null;

            try
            {
                var model = this.Context.Employees.Where(p => p.ID == entity.ID).FirstOrDefault();


                if (model != null)
                {

                    if (entity.ID != null)
                    {
                        model.ID = entity.ID.Value;
                    }

                    if (entity.FirstName != null)
                    {
                        model.FirstName = entity.FirstName;
                    }

                    if (entity.LastName != null)
                    {
                        model.LastName = entity.LastName;
                    }

                    if (entity.Gender != null)
                    {
                        model.Gender = entity.Gender;
                    }

                    if (entity.Salary != null)
                    {
                        model.Salary = entity.Salary.Value;
                    }

                    if (entity.DepartmentId != null)
                    {
                        model.DepartmentId = entity.DepartmentId.Value;
                    }

                    this.Context.Employees.Update(model);
                    this.SaveChanges();

                    // refresh entity
                    returnValue = this.Context.Employees.Where(p => p.ID == entity.ID).FirstOrDefault();;

                }

            }
            catch (Exception ex)
            {
                logger.LogError(ex, ex.Message);
            }

            return returnValue;
        }

    }
}

Generating the API

To generate the API, an ASP.NET Core web application is created and a reference is added to the project containing our entities, DTOs and Services.
The Context is configured in the Program.cs as well as the Services in the DI container.




builder.Services.AddDbContext<EmployeeContext>(options =>
  options.UseSqlite(builder.Configuration.GetConnectionString("TestConnectionString"), b=> b.MigrationsAssembly("WebApi")));

builder.Services.AddTransient<IEmployeeService, EmployeeService>();
builder.Services.AddTransient<IAuditEntryService, AuditEntryService>();
builder.Services.AddTransient<IDepartmentService, DepartmentService>();

A t4 template is added to generate the container and modified to produce the correct file names and code.

The code below shows a sample of the generated API controller



//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated from a template.
//
//     Manual changes to this file may cause unexpected behavior in your application.
//     Manual changes to this file will be overwritten if the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

namespace WebApi.Controllers
{
    using System;
    using System.Collections.Generic;

    using DataAccess.DTO;
    using DataAccess.Entities;
    using DataAccess.Interfaces;
    using DataAccess.Context;
    using Microsoft.Extensions.Logging;
    using Microsoft.AspNetCore.Mvc;

    [ApiController]
    [Route("api/[controller]")]
    public partial class DepartmentController : ControllerBase
    {
        private readonly IDepartmentService departmentService;

        public DepartmentController(IDepartmentService departmentService)
        {
            this.departmentService = departmentService;
        }


        [HttpGet]
        public async Task<IActionResult> GetListAsync()
        {
            var response = this.departmentService.GetAll();
            return await Task.FromResult(new JsonResult(response));
        }

        [HttpGet("{id}")]
        public async Task<IActionResult> GetOne(int? id)
        {
            var response = this.departmentService.GetOne(id);
            return await Task.FromResult(new JsonResult(response));
        }

        [HttpPost]
        public async Task<IActionResult> CreateAsync(Department entity)
        {
            var response = this.departmentService.Add(entity);
            return await Task.FromResult(new JsonResult(response));
        }
    }
}

We now have the API generated using T4 template and we can do a smoke test.
The migrations are created and the database is initialized. After that, we can run the application and everything works fine.

Benefits

The code generated can be added to source control the t4 template can be eliminated.
The build system does not necessarily have to process the text templates

Possible restrictions

T4 templates may be dropped in favor of Source Generators (to be implemented in the future). As long as they are supported in VS, this approach will work.

The code can be found here on github.

Enjoy your free time after this automation.

File upload with Arduino and GSM

Miiro Ashirafu — Tue, 28 Apr 2020 14:55:45 +0000

Have you ever tried uploading a file with the arduino and GSM from an SD card? I have started some work on it using Sim800l and I invite collaborators and advisers on how to perfect it and enable sending of larger data sets on my repo here.
So far, the code can upload a file with some fewer lines and I have tested it with around 10 in a csv file.