This project was born from a very simple frustration:

• I was tired of recreating the same basic value objects (email, phone number, names, MIME types, etc.) in every project.

• I wanted to standardize data across applications instead of having a different string format and validation rule in each solution.

• I did not want to create a huge “framework” or “super library” that you install for one useful type and then carry hundreds of classes you never use.

So instead, I decided to build a set of small, independent libraries, each one doing one thing well, and all following the same philosophy.

Philosophy: Small, Focused and Standards-Based

PosInformatique.Foundations is not a framework. It is a toolbox of tiny building blocks:

• Granular: each package is independent, lightweight, minimal.

• Composable: you install only what you need.

• Practical: most packages are about value objects, helpers, and small utilities that are missing in many projects.

• Standards-based: whenever possible, implementations follow existing standards:

  • Email addresses: RFC 5322

  • Phone numbers: E.164

  • MIME types: IANA media types

• Integration-specific packages: instead of making the core value object depend on everything, I provide derived packages per technology:

  • DataAnnotations

  • FluentValidation

  • Entity Framework Core

  • System.Text.Json

  • etc.

You can use the core value objects alone, or plug them into Entity Framework Core, validation, or JSON serialization with the packages you need.

All libraries target .NET 8.0, .NET 9.0 and .NET 10.0.

Main Features in 1.0.0

Email Address Value Object

Package: PosInformatique.Foundations.EmailAddresses
Plus integrations: EF Core, FluentValidation, System.Text.Json.

This package provides a strongly-typed EmailAddress value object with:

• Validation based on RFC 5322

• Normalization (for example on casing of the local and domain parts)

• Equality and comparison on the normalized form

Why it helps:

• No more string email arguments everywhere.

• You avoid inconsistent regexes and ad-hoc checks in each project.

• You can share a standard, tested implementation across many solutions.

Phone Number Value Object (E.164)

Package: PosInformatique.Foundations.PhoneNumbers
Plus integrations: EF Core, FluentValidation, System.Text.Json.

The PhoneNumber value object represents numbers in E.164 format:

• Parsing with region-aware support for local numbers

• Validation and normalization to a single, canonical form

• Helpers for formatting and comparison

This gives you consistent phone numbers across your system:

• One normalized representation

• Easier matching and comparisons

• No more half-baked "+33" vs "0033" vs local format issues

First/Last Name Value Objects

Package: PosInformatique.Foundations.People
Plus integrations: DataAnnotations, FluentValidation, FluentAssertions, EF Core, System.Text.Json.

These packages provide:

• FirstName and LastName value objects with normalization and validation

• Integration with:

  • DataAnnotations for ASP.NET MVC / Blazor forms

  • FluentValidation for more advanced validation rules

  • Entity Framework Core for persistence

  • System.Text.Json for serialization

Goal: stop using raw strings for user names and apply shared rules across your application with the following conventions:

• The last name are in uppercase and allows only one space as separator and alphabetic characters.

• The first name starts with uppercase and the letters are in lower case. The hypen and one spaces are allowed for separators.

MimeType Value Object

Package: PosInformatique.Foundations.MediaTypes
Plus integrations: EF Core, System.Text.Json.

MimeType is an immutable value object that represents a media type like image/png or application/pdf, with:

• A list of well-known MIME types

• Helpers to map between extensions and media types

• Strong typing instead of string everywhere

• Functional helpers to determine if a MIME type is an image, Auto CAD drawing,…

Text Templating: Building Emails (and More) From Models

Emailing is a simple but essential feature in almost every application. I wanted a way to:

• Define strongly-typed email templates with a model

• Use different templating engines (Razor, Scriban, …)

• Keep the email sending logic decoupled from the rendering engine

This is why I introduced two building blocks:

1. Text templating abstractions

   • Package: PosInformatique.Foundations.Text.Templating

   • Provides:

     • TextTemplate<TModel> base class

     • ITextTemplateRenderContext

   • Idea: define a clear contract for “take a model and render text”.

2. Concrete implementations

   • PosInformatique.Foundations.Text.Templating.Razor

     • Razor-based templating using Blazor components

     • Strongly-typed models

     • Full dependency injection support

   • PosInformatique.Foundations.Text.Templating.Scriban

     • Scriban-based templating with mustache-style syntax

     • Strongly-typed models mapped to template data

On top of that, there is an emailing infrastructure:

• PosInformatique.Foundations.Emailing

• Plus providers:

  • PosInformatique.Foundations.Emailing.Azure (Azure Communication Service)

  • PosInformatique.Foundations.Emailing.Graph (Microsoft Graph API)

You can:

• Register email templates (subject + body) as text templates

• Render them from a model (e.g., PasswordResetModel, WelcomeUserModel, etc.)

• Send them via a chosen provider

The nice part is that this text templating mechanism is generic. It is not limited to emails:

• You can reuse it to generate:

  • SMS content

  • Notifications

  • System messages

  • Any other text-based messages from a model

Why Not One Big Library?

I intentionally avoid a single “mega package” that does everything.

Instead:

• Each package has a single responsibility.

• There is no hard coupling between them (only logical relationships).

• You choose:

  • Only the value objects you need (email, phone, names, MIME types, …)

  • Only the integrations you need (EF, JSON, validation, …)

  • Only the emailing pieces you actually use.

This keeps your dependencies clean and your binaries smaller, and it avoids installing 98% of unused code just for one class. Also, because the library are very small, you can use it in Blazor WASM applications which requires binaries as small as possible for the startup of the application.

.NET Compatibility And Dependencies

All PosInformatique.Foundations packages target:

• .NET 8.0

• .NET 9.0

• .NET 10.0

For external dependencies, I intentionally target relatively old versions (for example Microsoft.Graph) to stay compatible with more projects.

If you need newer versions in your solution, you can simply:

• Add an explicit reference to the newer dependency in your application

• Let NuGet resolve the latest version for that library

• Still use PosInformatique.Foundations without issues

This approach keeps the libraries flexible and avoids forcing a full update of your stack.

Real-World Usage

These libraries are not theoretical. I built them to solve real problems in real applications.

PosInformatique.Foundations is currently used in the development of SaaS applications at:

• Chantier Connect: A 360° application for desktop, tablet, and phone, and a kiosk to track the progress of construction sites.

• Artahe Solutions: A software editor that allows the creation of activity tracking reports.

The goal is to reuse the same reliable building blocks across multiple products, rather than copy-pasting the same pieces of code again and again.

Getting Started

All packages are available on NuGet.
The full list is in the GitHub repository: PosInformatique.Foundations

From there you can:

• Browse each package README

• Copy installation commands

• See examples, supported scenarios, and integration details

Conclusion

PosInformatique.Foundations is my attempt to provide simple, reusable .NET foundations for everyday work:

• Strongly-typed value objects for email, phone numbers, names, MIME types

• A clean text templating abstraction

• A flexible emailing infrastructure

• Small, modular packages instead of one big framework

• Based on standards and compatible with .NET 8–10

If you are a .NET developer who is tired of rewriting the same value objects and basic infrastructure, I hope these libraries will save you time and bring more consistency to your projects.

If you try them, I would be happy to hear your feedback and suggestions for future improvements.

For example, if we have the following business object:

public class Person
{
    public Person(int id, string firstName, string lastName)
    {
        this.Id = id;
        this.FirstName = firstName;
        this.LastName = lastName;
    }

    public int Id { get; }

    public string FirstName { get; }

    public string LastName { get; }
}

And the JSON DTO version used to expose it as a Web API:

public class PersonJson
{
    public PersonJson(int id, string firstName, string lastName)
    {
        this.Id = id;
        this.FirstName = firstName;
        this.LastName = lastName;
    }

    [JsonPropertyName("id")]
    public int Id { get; }

    [JsonPropertyName("firstName")]
    public string FirstName { get; }

    [JsonPropertyName("lastName")]
    public string LastName { get; }
}

The extension method that allows converting from Person to PersonJson could look like this:

public static class PersonJsonExtensions
{
    public static PersonJson ToJson(this Person person)
    {
        return new PersonJson(person.Id, person.FirstName, person.LastName);
    }
}

And the usage inside an ASP.NET Core controller is straightforward:

[ApiController]
[Route("persons")]
public class PersonController : ControllerBase
{
    private readonly IPersonManager manager;

    public PersonController(IPersonManager manager)
    {
        this.manager = manager;
    }

    [HttpGet("byId/{id}")]
    public PersonJson GetById(int id)
    {
        var person = this.manager.GetByID(id);
        var personJson = person.ToJson();

        return personJson;
    }

    [HttpGet("byName/{name}")]
    public PersonJson GetByName(string name)
    {
        var person = this.manager.GetByName(name);
        var personJson = person.ToJson();

        return personJson;
    }
}

However, this approach can complicate unit testing. In this article, I'll explain an alternative method using an interface to decouple the code, which makes testing easier.

The problem with extension methods

While this approach works, the problem arises during unit testing. You need to test both the code that retrieves the business entity (the GetById() or GetByName() methods) and the code that converts it to JSON. This makes your tests more complex and harder to maintain.

For example, to test our PersonController, we would write the following unit tests:

public class PersonControllerTest
{
    [Fact]
    public void GetById()
    {
        // Arrange
        var person = new Person(1, "John", "DOE");

        var manager = new Mock<IPersonManager>(MockBehavior.Strict);
        manager.Setup(m => m.GetByID(1234))
            .Returns(person);

        var controller = new PersonController(manager.Object);

        // Act
        var json = controller.GetById(1234);

        json.FirstName.Should().Be("John");
        json.Id.Should().Be(1);
        json.LastName.Should().Be("DOE");

        // Assert
        manager.VerifyAll();
    }

    [Fact]
    public void GetByName()
    {
        // Arrange
        var person = new Person(1, "John", "DOE");

        var manager = new Mock<IPersonManager>(MockBehavior.Strict);
        manager.Setup(m => m.GetByName("Someone"))
            .Returns(person);

        var controller = new PersonController(manager.Object);

        // Act
        var json = controller.GetByName("Someone");

        // Assert
        json.FirstName.Should().Be("John");
        json.Id.Should().Be(1);
        json.LastName.Should().Be("DOE");

        manager.VerifyAll();
    }
}

As you can see, in these unit tests, for each use of the ToJson() extension method, we have to test the mapping of each property. These unit tests are quite simple, but imagine a controller that makes many different calls to the ToJson() extension method, especially if the Person/PersonJson objects have many properties.

The solution: Create an external mapper

To simplify testing, we can move the conversion logic into a separate class by introducing a simple interface called IPersonJsonMapper. Here's how:

1. Define the interface:

    public interface IPersonJsonMapper
    {
        PersonJson ToJson(Person person);
    }
   

2. Implement the interface:

    public class PersonJsonMapper : IPersonJsonMapper
    {
        public PersonJson ToJson(Person person)
        {
            return new PersonJson(person.Id, person.FirstName, person.LastName);
        }
    }
   

3. Use the interface in our controller:

    [ApiController]
    [Route("persons")]
    public class PersonController : ControllerBase
    {
        private readonly IPersonManager manager;
   
        private readonly IPersonJsonMapper jsonMapper;
   
        public PersonController(IPersonManager manager, IPersonJsonMapper jsonMapper)
        {
            this.manager = manager;
            this.jsonMapper = jsonMapper;
        }
   
        [HttpGet("byId/{id}")]
        public PersonJson GetById(int id)
        {
            var person = this.manager.GetByID(id);
            var personJson = this.jsonMapper.ToJson(person);
   
            return personJson;
        }
   
        [HttpGet("byName/{name}")]
        public PersonJson GetByName(string name)
        {
            var person = this.manager.GetByName(name);
            var personJson = this.jsonMapper.ToJson(person);
   
            return personJson;
        }
    }
   

4. Register the mapper as service in the Program.cs file:

builder.Services.AddSingleton<IPersonJsonMapper, PersonJsonMapper>();

The code of the controller remains as simple as when using the ToJson() extension method, but now the unit test becomes easier:

public class PersonControllerTest
{
    [Fact]
    public void GetById()
    {
        // Arrange
        var person = new Person(default, default, default);
        var personJson = new PersonJson(default, default, default);

        var manager = new Mock<IPersonManager>(MockBehavior.Strict);
        manager.Setup(m => m.GetByID(1234))
            .Returns(person);

        var mapper = new Mock<IPersonJsonMapper>(MockBehavior.Strict);
        mapper.Setup(m => m.ToJson(person))
            .Returns(personJson);

        var controller = new PersonController(manager.Object, mapper.Object);

        // Act
        var json = controller.GetById(1234);

        // Assert
        json.Should().BeSameAs(personJson);

        manager.VerifyAll();
        mapper.VerifyAll();
    }

    [Fact]
    public void GetByName()
    {
        // Arrange
        var person = new Person(default, default, default);
        var personJson = new PersonJson(default, default, default);

        var manager = new Mock<IPersonManager>(MockBehavior.Strict);
        manager.Setup(m => m.GetByName("Someone"))
            .Returns(person);

        var mapper = new Mock<IPersonJsonMapper>(MockBehavior.Strict);
        mapper.Setup(m => m.ToJson(person))
            .Returns(personJson);

        var controller = new PersonController(manager.Object, mapper.Object);

        // Act
        var json = controller.GetByName("Someone");

        // Assert
        json.Should().BeSameAs(personJson);

        manager.VerifyAll();
        mapper.VerifyAll();
    }
}

As you can see, now we don't need to assert the content of the PersonJson object because it's not the controller's responsibility. Also, I intentionally instantiate the Person and PersonJson objects with default values, since the code being tested will not use them. Of course, we could use a library like AutoFixture to easily instantiate these objects.

var person = new Person(default, default, default);
var personJson = new PersonJson(default, default, default);

Unit test the mapper

Even though we don't need to assert the content of the PersonJson instance in the controllers, we should still assert the conversion from a Person instance to a PersonJson by adding a unit test for the PersonJsonMapper class:

public class PersonJsonMappingTest
{
    [Fact]
    public void ToJson()
    {
        // Arrange
        var person = new Person(1234, "John", "DOE");

        var mapper = new PersonJsonMapper();

        // Act
        var json = mapper.ToJson(person);

        // Assert
        json.FirstName.Should().Be("John");
        json.Id.Should().Be(1234);
        json.LastName.Should().Be("DOE");
    }
}

Change the implementation of the mapper

By delegating the conversion to a dedicated class, we can also easily change the implementation using another mapper library, such as AutoMapper.

Using this approach allows you to change the library or the mapping logic easily without altering the code in the controller.

Conclusion

Delegating data conversion to another class makes your code more testable and maintainable. This approach can be applied at various levels, whether in controllers to convert XML/JSON to entities or in the data access layer for converting Entity Framework entities to business entities. By using this approach, you also respect the "Single Responsibility" principle of the S.O.L.I.D. principles.

A complete example of the source of this article is available within one of my public GitHub projects: GillesTourreau/GillesTourreau.ModelMapper: Example project to delegate the conversion of entity model to JSON in other class (github.com).

When building modern web applications, security is always a top priority. In ASP.NET Core, authentication is a key part of ensuring that only authorized users can access specific parts of your application. You may often need to support multiple authentication schemes, such as different Azure Entra ID (formerly Azure AD) configurations, within the same application.

One challenge when using multiple authentication schemes is identifying which scheme authenticated a user. This is where the ClaimsIdentity.AuthenticationType property comes into play. Setting this property correctly can help you easily determine the authentication source for a user.

Understanding HttpContext.User

In ASP.NET Core, the HttpContext.User property represents the current authenticated user. This user is represented by a ClaimsPrincipal object, which contains one or more ClaimsIdentity objects. Each ClaimsIdentity represents a specific identity associated with the user, such as a name, roles, and other claims.

By default, the AuthenticationType is set to "AuthenticationTypes.Federation". However, when working with multiple authentication schemes, you might want to know exactly which authentication scheme was used to create a particular ClaimsIdentity. This is where setting a custom AuthenticationType can be very useful.

For example, let’s say you want to retrieve the AuthenticationType of the currently authenticated user to determine how they were authenticated:

public IActionResult GetAuthenticationType()
{
    var identity = HttpContext.User.Identity as ClaimsIdentity;

    if (identity != null)
    {
        string authenticationType = identity.AuthenticationType;
        return Ok($"User authenticated using: {authenticationType}");
    }

    return BadRequest("No identity found.");
}

This example demonstrates how you can access the AuthenticationType in your controller to gain insights into the user's authentication method.

The Problem with Multiple Authentication Schemes

When you have multiple authentication schemes, such as two different configurations for Azure Entra ID, it's not always clear which scheme authenticated the user. Without setting the AuthenticationType, you may not be able to distinguish between the identities created by different schemes. This can be problematic in scenarios where your application's logic depends on the authentication source.

Setting the AuthenticationType

To set the AuthenticationType in ASP.NET Core, you need to configure it in the TokenValidationParameters when setting up your authentication schemes. The TokenValidationParameters.AuthenticationType property allows you to specify a unique identifier for the authentication scheme, which is then assigned to the ClaimsIdentity.AuthenticationType.

For example, let's say you have two Azure Entra ID configurations: one for internal users and another for external partners. You can set up your authentication schemes as follows:

public void ConfigureServices(IServiceCollection services)
{
    // Internal users authentication scheme
    services.AddAuthentication("InternalScheme")
        .AddMicrosoftIdentityWebApi(options =>
        {
            options.Instance = "https://login.microsoftonline.com/";
            options.Domain = "internaldomain.com";
            options.ClientId = "your-client-id";
            options.TenantId = "your-tenant-id";

            // Set the AuthenticationType for the internal scheme
            options.TokenValidationParameters.AuthenticationType = "Internal";
        });

    // External partners authentication scheme
    services.AddAuthentication("ExternalScheme")
        .AddMicrosoftIdentityWebApi(options =>
        {
            options.Instance = "https://login.microsoftonline.com/";
            options.Domain = "externaldomain.com";
            options.ClientId = "your-client-id";
            options.TenantId = "your-tenant-id";

            // Set the AuthenticationType for the external scheme
            options.TokenValidationParameters.AuthenticationType = "External";
        });
}

Retrieving the AuthenticationType

Now that you've configured the AuthenticationType for each scheme, you can retrieve it later in your code to determine which scheme authenticated the user:

public IActionResult GetUserIdentity()
{
    var identity = HttpContext.User.Identity as ClaimsIdentity;

    if (identity != null)
    {
        string authenticationType = identity.AuthenticationType;
        return Ok($"User authenticated using: {authenticationType}");
    }

    return BadRequest("No identity found.");
}

Conclusion

By setting the AuthenticationType in the TokenValidationParameters, you can clearly distinguish between different authentication schemes in ASP.NET Core. This approach is especially useful when your application needs to support multiple authentication sources, such as different Azure Entra ID configurations. With this setup, you'll be able to write more precise and secure authentication logic in your application.

Origin and Purpose

This analyzer was born from the need to fortify unit tests by detecting discrepancies during the coding phase. I wanted to preemptively identify errors in my Moq based tests to ensure their coherence and correctness.

For that I used the .NET Compiler Platform SDK to create an analyzer packaged inside a NuGet package.

What's new in the version 1.3.0?

The recent release, version 1.3.0, brings a significant advancement: the PosInfoMoq2003 rule. This rule inspects method signature within Callback() to validate their alignment with Setup() method.

For exemple, in the following mocked method UpdateAsync(), the analyzer check that the Callback() method take a lambda expression with exactly the same signature.

var repository = new Mock<ITaskRepository>(MockBehavior.Strict);
repository.Setup(r => r.UpdateAsync(task, It.IsAny<TaskChangeTracking>()))
    .Callback((TaskUpdate _, TaskChangeTracking updated) =>
    {
        updated.DateTime.Should().Be(new DateTime(2023, 1, 2, 3, 4, 5, 6)).And.BeIn(DateTimeKind.Utc);
        updated.UserId.Should().Be("55555555-5555-5555-5555-555555555555");
    })
    .Returns(Task.CompletedTask);

This enhancement significantly boosts the analyzer's ability to ensure method coherence within Moq setups.

A quick recap of the previous versions

Let's recall the enhancements of the previous versions. They introduced rules like PosInfoMoq1000 and PosInfoMoq1001, emphasizing the importance of invoking Verify() or VerifyAll() methods and defining Mock<T> instances to Strict mode.

Also, other additional rules was added, to perform immediate compilation validation, aiming to catch errors before runtime execution, ensuring higher code quality and mitigating potential issues during the testing phase.

• PosInfoMoq2000: Requires the use of Returns() or ReturnsAsync() methods for Strict mocks. This rule ensures that when defining a Mock<T> with Strict behavior, these methods are invoked when setting up a method to mock returning a value.

• PosInfoMoq2001: Check the usage of the Setup() method to be use on overridable members (not extension method, not sealed).

• PosInfoMoq2002: Specifies that the Mock<T> class can only be used to mock non-sealed classes (interfaces of abstract classes).

For instance, this is a simple unit test which matches four of the previous rules of the PosInformatique.Moq.Analyzers analyzer.

[Fact]
public async Task GetAsync()
{
    var visits = new[]
    {
        new Visit(default, default, default),
    };

    var manager = new Mock<IVisitManager>(MockBehavior.Strict);  // PosInfoMoq1001 : Check that mock are defined to Strict mode.
    manager.Setup(m => m.FindAsync(It.IsAny<VisitQuery>()))
        .Callback((VisitQuery q) =>  // PosInfoMoq2003: Check the signature to match with the Setup() mocked method.
        {
            q.Should().BeEquivalentTo(new VisitQuery()
            {
                Id = new Guid("11111111-1111-1111-1111-111111111111"),
            });
        })
        .ReturnsAsync(visits);  // PosInfoMoq2000: Returns() or ReturnsAsync() is required.

    var result = await manager.Object.GetAsync(new Guid("11111111-1111-1111-1111-111111111111"));

    result.Should().BeSameAs(visits[0]);

    manager.VerifyAll();  // PosInfoMoq1000 : Check that the Verify() / VerifyAll() method is called in the unit test.
}

For detailed installation instructions and a comprehensive list of rules, refer to the official documentation available on the github.io website.

Useful Links

• Official Documentation: Access the detailed documentation for PosInformatique.Moq.Analyzers.

• GitHub Repository: Explore and contribute to the analyzer's development on PosInformatique.Moq.Analyzers GitHub repository.

For instance, in a Dispose() method, it's valuable to ascertain if an exception is already in progress to avoid throwing a new exception and losing the original one.

Problem encountered

I encountered this issue in a complex scenario within my unit tests. In a mocked Dispose() method, I aimed to throw an exception if an assertion had failed. However, the problem arose when an exception occurred within a using block of my disposable object, triggering the Dispose() method. This prevented me from retrieving the original exception in the log during the unit test execution in the CI process.

NOTE: Belong the Microsoft CA1065 recommandation, a Dispose() method must not throw an exception.

Below is a simplified example code depicting this scenario:

public class MyCode
{
    public void Example()
    {
        using (var obj = new DisposableObject())
        {
            var divisor = 0;
            var result = 10 / divisor;
        }
    }
}

public class DisposableObject : IDisposable
{
    private bool methodCalled;

    public void CallBeforeDispose()
    {
        this.methodCalled = true;
    }

    public void Dispose()
    {
        if (!this.methodCalled)
        {
            throw new XunitException("The CallBeforeDispose() has not been called.");
        }
    }
}

As you can see, the Example() method will throw an exception because we did not call the CallBeforeDispose() method. In this scenario, an exception is thrown inside the using block code, leading to the invocation of the Dispose() method of the DisposableObject. This invocation will raise another XunitException exception. Consequently, in this situation, we will lose the original DivideByZeroException exception.

The Marshal.GetExceptionPointers() method.

To determine if an exception is ongoing, the .NET provides a straightforward static method called Marshal.GetExceptionPointers() which returns an unmanaged pointer to the ongoing exception.

• A zero pointer returned by this method indicates that no exception is ongoing.

• Conversely, a non-zero pointer returned by the method indicates an ongoing exception.

We can leverage this behavior to detect if an exception is ongoing within our Dispose() method:

public void Dispose()
{
    if (!this.methodCalled)
    {
        // Do not thrown an exception, if an exception is currently ongoing.
        if (Marshal.GetExceptionPointers() == IntPtr.Zero)
        {
            throw new XunitException("The CallBeforeDispose() has not been called.");
        }
    }
}

.NET Standard and Marshal.GetExceptionPointers()

If you refer to the table "Applies to" table at the bottom of Marshal.GetExceptionPointers() documentation page, you'll notice that this method is available in .NET Core and .NET Framework libraries but not in the .NET Standard.

To overcome this limitation, we simply employ reflection to access the static GetExceptionPointers() method within the Marshal class.

I've created a straightforward helper class that can be utilized in projects targeting both .NET Standard and non-.NET Standard frameworks (especially useful for building libraries intended for various frameworks).

When incorporating the helper into a .NET Standard library, I use expressions to dynamically compile a call, avoiding reflection and enhancing performance when invoking the IsExceptionOnGoing() method.

using System;
#if NETSTANDARD
using System.Linq.Expressions;
#endif
using System.Runtime.InteropServices;

public static class ExceptionHelper
{
    public static bool IsExceptionOnGoing()
    {
        var ptr = GetExceptionPointers();

        if (ptr == IntPtr.Zero)
        {
            return false;
        }

        return true;
    }

#if NETSTANDARD
    private static readonly Func<IntPtr> GetExceptionPointers = BuildGetExceptionPointersFunc();

    private static Func<IntPtr> BuildGetExceptionPointersFunc()
    {
        var memberAccess = Expression.Call(typeof(Marshal).GetMethod("GetExceptionPointers"));

        var lambda = Expression.Lambda<Func<IntPtr>>(memberAccess);

        return lambda.Compile();
    }
#else
    private static IntPtr GetExceptionPointers()
    {
        return Marshal.GetExceptionPointers();
    }
#endif
}

A complete example of this helper class is available within one of my public GitHub projects: GillesTourreau/GillesTourreau.AmbientException: Example and helper class to detect ongoing .NET exceptions (github.com)

I've hit refresh on my blog, clearing out the cobwebs of a site stuck in 2014! For those familiar with my old space, it's time for a brand-new journey. This blog remains dedicated to Microsoft technologies – delving deep into the realms of .NET and Azure.

Why the reboot? It's simple. My burning desire lies in sharing. I'm passionate about unraveling the intricacies of my daily tech encounters, the problems I solve, and the knowledge I gather. And when it comes to crafting articles, HashCode has become my trusty companion, speeding up the process compared to WordPress.

One significant change – while the previous blog was in French, this time, it's all about English. Here's to a new language and a fresh tech adventure!

Let's dive in together!

PS: Don't hesitate to join me on this journey. Let's dive in together!