Hey there, readers! I’m NIZZOLA, a developer and AI enthusiast. Today, I’m excited to share a project I built specifically to optimize large language model (LLM) workflows and AI-driven applications: NIZZOLA.TOON.NET, a serializer for Token-Oriented Object Notation (TOON). Designed with token efficiency in mind, TOON addresses the high costs and latency of traditional JSON when interacting with LLM APIs.

This article is based on the GitHub repository and highlights the key benefits of using this format, along with the ease of implementation using my .NET library. Let’s dive in!

What is TOON?

Token-Oriented Object Notation (TOON) is a compact, token-efficient serialization format tailored for AI and LLM workloads. Unlike JSON, which is often bloated with braces, quotes, and commas, TOON minimizes token usage through smart strategies like optimized indentation, automatic tabular detection, and CSV-style compact arrays.

The result? A format that’s not only smaller but also human-readable — perfect for debugging, prompt engineering, and feeding structured data into models like GPT, Grok, or Claude. The full implementation is available in the .NET library, ready for production use.

Key Benefits of Using TOON

The standout advantage of TOON is its ability to reduce token consumption by ~30–60% compared to JSON. In LLM-powered systems where every token has a cost, this translates into real-world savings. Here are the core benefits:

• Lower API Costs for LLMs: By sending fewer tokens to models like OpenAI or Grok, you directly reduce operational expenses. Ideal for high-volume or tabular data workflows.
• Faster End-to-End Response Times: Less data means quicker serialization, transmission, and processing — leading to improved latency and throughput.
• Superior Readability for Debugging: Despite its compactness, TOON uses clean indentation and structure, making it easy to inspect prompts and model outputs.
• Smart Tabular Detection: Automatically identifies homogeneous object lists and serializes them as a header + rows table. The more rows, the greater the savings!
• Flexible & Extensible: Supports naming policies (camelCase, snake_case), streaming, async operations, and easy customization via attributes.

In short, TOON is an evolution of data serialization — built for the era of token-based AI.

Effortless Implementation with NIZZOLA.TOON.NET

I designed the library with .NET developers in mind. The API mirrors System.Text.Json.JsonSerializer, so adoption is seamless. Let’s see how easy it is to get started.

Quick Installation

Add the package via NuGet:

dotnet add package Nizzola.TOON.NET

That’s it — you’re ready to serialize.

Simple Usage Examples

Basic serialization and deserialization:

// Serialize
var toon = ToonSerializer.Serialize(obj, new ToonSerializerOptions 
{ 
    Indentation = 2, 
    NamingPolicy = NamingPolicy.CamelCase 
});

// Deserialize
var model = ToonSerializer.Deserialize<MyModel>(toon);

Async and stream support:

// Async serialization
await ToonSerializer.SerializeAsync(stream, obj, options);
// Async deserialization
var result = await ToonSerializer.DeserializeAsync<MyModel>(stream);

Pro Tips:

• Use Indentation = 2 for the best balance of readability and compactness.
• Enable tabular detection for large, uniform lists to maximize savings.
• Match NamingPolicy to your LLM’s expected conventions (e.g., camelCase for English prompts).

You can also use [ToonIgnore] to skip properties and fine-tune behavior with ToonSerializerOptions.

Before & After: TOON vs JSON

ScenarioJSONTOONSavingsSingle data type listVerbose, repetitive keysCompact header + rows~40%Mixed data typesFull object nestingSmart indentation, minimal quotes~30–50%

The more structured and repetitive the data, the bigger the win.

Test 1

Test 2

Core Library Features

SymbolComponentPurpose🔧ToonSerializerMain sync/async API✍️ToonWriterHigh-performance formatting engine⚙️ToonSerializerOptionsIndentation, naming, tabular detection🚫ToonIgnoreAttributeExclude properties

Built on StringBuilder with optimized reflection caching, the library ensures blazing-fast performance. It supports CLR types, JSON-to-TOON conversion, and streaming scenarios.

Why Adopt TOON? Real-World Impact

TOON isn’t just a format — it’s a strategic advantage for AI developers. With NIZZOLA.TOON.NET, you get:

• Immediate token savings → lower costs
• Faster pipelines → better performance
• Familiar .NET API → zero learning curve
• Production-ready, MIT-licensed, open-source

Whether you’re building prompt pipelines, data processors, or agent systems, TOON helps you do more with less.

Get Started Today

Head over to the GitHub repo to explore the code, examples, and benchmarks. The library is NuGet-ready and battle-tested for LLM workflows.

If you find it useful, consider supporting development with a coffee: Buy me a coffee! ☕

Follow me for more dev & AI content: LinkedIn | Medium | Instagram | Linktree

Thanks for reading! Have you tried TOON in your projects? Drop a comment below — I’d love to hear your thoughts! 🚀

After the article about Testcontainers (if you missed it, here’s the link), a question arises: why don’t we validate our tests when creating a pull request?

How can we do this? Github Actions (learn more) allows you to create actions within GitHub to run scripts, such as unit test validation!

For this, I’ll use the same project I demonstrated in the Testcontainers article, creating a script to run the tests.

Since this project has multiple unit tests, I’ll focus initially only on the tests for the project that uses Testcontainers: “Store.Infra.Data.Sql.Tests.csproj”.

To get started, how about a little help from GitHub itself? In your repository, click the “Actions” icon to use the built-in setup assistant:

A template will be displayed for editing and filling in your project details:

Now, just fill in the folders and names of your project items:

1 — Solution name
2 — Repeat the solution name
3 — Project name (or you could keep the entire solution if you want to test everything). In this case, I chose to test only one project!

Done! Save by clicking the “Commit Changes” button at the top of the window. It will prompt you to create a pull request with these changes. At this point, since the pull request is created, the GitHub Actions process will automatically start, running the tests.

Note that in lines 7–10, the actions where the script will run are configured — specifically, for “push” to the “main” branch and “pull request” to the “main” branch. You can modify these for other scenarios if needed.

As a result, we see that the process ran successfully!

If we click on that execution line, we can see the general details:

And if we click the “build” button, we can see each step of the execution flow:

To see the details of each step, just click on it:

Now we have a setup that runs tests every time a pull request is made to the “main” branch and validates whether it worked!

But everything looks too perfect — let’s cause some trouble! I’ll edit and remove an important line in the test project and create a new pull request.

As soon as the test pipeline runs, we can see something went wrong. The pull request shows that the test failed!

Let’s check Actions to see what happened. Right away, we see an execution history where one of them failed:

Looking at the details, we can see where it failed. If we click, we can even see the error log:

We see it was in the test. Clicking will show the entire process so we can identify where it failed. Now we’ve found the problem — just fix it and create a new pull request!

Okay, I used my personal GitHub account, which has Actions enabled. But what if you don’t see the “Actions” button in your work repository? Simple — it needs to be enabled for the organization. For individual users, it’s free up to 2000 minutes per month! It’s time for the boss to open their wallet and enable GitHub Actions — the benefits pay for themselves and can prevent a pull request from breaking an application!

Did you like the article? Click the 👏 icon and follow me to see upcoming publications! If you like to see more publications see my networks into my linktree: https://linktree.com/nizzola

Testing the implementation of a repository by validating the saving of elements in the database is not a very easy task, and working with Mocks or In-Memory Databases is not always possible either. If you mix the use of Entity Framework and Dapper or raw SQL commands via SqlClient, you’ll see that In-Memory won’t work.

This is where the Testcontainers library (https://dotnet.testcontainers.org/) comes in. It’s a library made for .NET but has equivalents for other languages, as shown in the image below (taken from the website). There’s even one for Java!

Jokes aside, I decided to test it in an application I already had, and to my surprise, it was very simple to use and quick to implement.

To start, I created a new unit test project for the SQL layer of my application, where I’ll test the Repository. First, I created a class where I’ll instantiate the context using the Docker container instance with the Microsoft SQL database.

My repository follows a very simple implementation pattern, adhering to this interface as shown in the source code below:

public interface IBaseRepository<T> where T : class
{
    Task<IEnumerable<T>> GetAll();
    Task<T> GetOne(Guid id);
    Task<bool> Create(T model);
    Task<bool> Update(T model);
    Task<bool> Delete(Guid id);
}

The Repository has the Context as a parameter in its constructor.

Therefore, our test will be based on the premise of creating a Docker instance where we’ll implement the “StoreContext” database and run the project’s migration so the database is created with all tables according to the last registered migration.

For this, we’ll create a class called ContainersFixture:

In the code blocks, we see the InitializeAsync method:

a) The block that creates the container — in this case, several parameters are passed to configure the Docker instance. After instantiating the object, the StartAsync command is executed to initialize it.

b) After instantiating the container object, in block b, we define some variables retrieved from the container instance and build the connection string.

c) In block c, we set up the context, which will be used to interact with the database instance created inside Docker.

d) Now, the Migration command is executed to create all tables in the database.

This is the first step. Now, we only need two more methods, shown below:

• GetContext will be used to obtain the context instance to inject into the repository.
• DisposeAsync will terminate and remove the container objects from memory, as well as pause Docker.

Now, let’s write the unit tests! We start by creating a StoreRepositoryTests class, and in its constructor, we’ll instantiate the Fixture class as shown in the code below. The red-highlighted area shows the repository being loaded in the constructor:

We also create a method to generate a Store instance within the class itself:

The CreateNew method creates an instance of the Store class (line 22), adds it to the database via the Create command (line 25), and then queries it using the repository’s GetOne method, reading the store’s ID (newstore.Id).

In lines 30 and 31, we verify:

• Whether the product was successfully retrieved (i.e., not null).
• Whether the product name matches the initial instance’s name.

Let’s write more tests in the class — one for the Delete command. In this method, we’ll create a new Store instance, add it to the database, and then delete it using the repository’s Delete method:

A test for the Update command, where we create a Store instance via Create, read it using GetOne, and then perform an Update, changing the store’s name. This is later verified in lines 69 and 70 to ensure it matches the information retrieved again from the database in line 67:

Now, just run the tests and validate the functionality! As soon as the container starts, you’ll see it appear in the Docker window (if you have Docker Desktop; otherwise, just run docker ps to see the instance running).

The Testcontainers library itself will handle the initialization and shutdown of the database instance in Docker after the tests finish.

So, what are we testing?
The StoreRepositoryTests class implements the unit tests for the StoreRepository, which in its constructor receives the context connected to the Test Container instantiated in ContainersFixture.

The class tests the repository’s CRUD operations — adding items, reading items from the database, deleting, and updating — ensuring the repository works as expected when connected to the database.

public class StoreRepositoryTests
{
    private readonly IStoreRepository _storeRepository;
    public StoreRepositoryTests()
    {
        var fixture = new ContainersFixture();
        fixture.InitializeAsync().Wait();
        var dbContext = fixture.GetContext();
        _storeRepository = new StoreRepository(dbContext, new FakeLogger<StoreRepository>());
    }

    [Fact]
    public async Task CreateNew()
    {
        var newStore = CreateInstance();

        // Act
        var response = await _storeRepository.Create(newStore);

        // Assert
        var product = await _storeRepository.GetOne(Guid.Parse(newStore.Id));

        Assert.NotNull(product);
        Assert.Equal(newStore.Name, product.Name);
    }

    [Fact]
    public async Task Delete()
    {
        var newStore = CreateInstance();

        // Act
        var response = await _storeRepository.Create(newStore);

        // Assert
        var product = await _storeRepository.GetOne(Guid.Parse(newStore.Id));

        Assert.NotNull(product);
        Assert.Equal(newStore.Name, product.Name);

        var deleteResponse = await _storeRepository.Delete(Guid.Parse(newStore.Id));
        Assert.True(deleteResponse);
        var deletedProduct = await _storeRepository.GetOne(Guid.Parse(newStore.Id));
        Assert.Null(deletedProduct);
    }

    [Fact]
    public async Task Update()
    {
        var newStore = CreateInstance();

        // Act
        var response = await _storeRepository.Create(newStore);

        // Assert
        var product = await _storeRepository.GetOne(Guid.Parse(newStore.Id));

        product.Name = "Updated Store Name";
        await _storeRepository.Update(product);
        var updatedProduct = await _storeRepository.GetOne(Guid.Parse(newStore.Id));

        Assert.NotNull(product);
        Assert.Equal(updatedProduct.Name, product.Name);
    }

    private StoreModel CreateInstance()
    {
        return new StoreModel
        {
            Id = Guid.NewGuid().ToString(),
            Name = "Test Store",
            Phone = "1234567890",
            Email = "abc@test.com"
        };
    }
}

With this, we can perform many tests that were previously incompatible with InMemoryDatabase, which didn’t allow direct SQL commands or the execution of Procedures and Views.

This example covers the use of SQL Server, but as per the library’s documentation, there’s support for many others, as seen in the image below:

Did you like the article? Click the 👏 icon and follow me to see upcoming publications! If you like to see more publications see my networks into my linktree: https://linktree.com/nizzola

References

Microsoft SQL Server — Testcontainers for .NET

When we use Guid to define unique non-numeric keys in .NET with the Guid.NewGuid command, which generates a UUID v4, there’s an issue: they don’t follow a chronological order. This means we often need to rely on other fields, such as creation or update dates, to sort records when querying a database.

However, .NET 9 introduces an exciting solution — a new type called UUID v7, which incorporates a timestamp in its structure, enabling natural sorting.

How to Create a UUID v7?

Using .NET 9, you can generate a UUID v7 with the following command:

var uuidWithDate = Guid.CreateVersion7();

By generating multiple UUIDs with a 10-second interval between them, you can observe the difference:

The structure consists of blocks based on date and time, combined with random components, allowing the UUIDs to be sorted.

This provides 122 bits of entropy, with 6 bits reserved for version and variant information embedded somewhere in the middle. The key advantage is that UUIDs can be sorted by creation time, making them more suitable for databases than UUID v4.

Controlling the Timestamp

Can we control the generation with different dates and times? This is often necessary for testing purposes. How can we achieve that?

The method supports a TimeProvider to control the DateTimeOffset.UtcNow:

var uuid = Guid.CreateVersion7(timeProvider.GetUtcNow());

Why is UUID v7 Better for Databases?

• Natural Sorting: Traditional databases often require additional columns to sort records by creation time. With UUID v7, sorting is inherent in the UUID itself, eliminating the need for extra columns.
• Optimized Indexing: Since UUID v7 is time-sortable, database indexing mechanisms can optimize data storage and retrieval, resulting in faster time-based queries.
• Concurrency and Distribution: Generating unique, sequential IDs in distributed systems can be challenging. UUID v7 can be generated simultaneously across multiple nodes without collision risks, making it ideal for distributed architectures.
• Lower Overhead: Unlike UUID v1, which could expose the machine’s MAC address (raising privacy concerns), UUID v7 avoids this issue, reducing the need for data masking or anonymization.
• Flexibility: Databases that support binary storage can store UUID v7 efficiently, and it can be easily encoded into other formats, such as strings, when needed.

What’s Next?

UUID v7 is now available in .NET 9, which was released a few months ago. You can start using it in your applications today to leverage its benefits for sorting and database optimization.

Did you enjoy the article? Click the 👏 icon, share it with your friends, and follow me for more posts! Want to see more content? Check out my social media via my Linktree: https://linktree.com/nizzola

References

Extend System.Guid with a new creation API for v7 · Issue #103658 · dotnet/runtime

For those who write unit tests using NSubstitute and .NET, it’s quite common to face challenges when testing log messages, since the Logger has some peculiarities that the NSubstitute library doesn’t handle very well.

There are numerous posts complaining about this on StackOverflow, where messages like the one below frequently appear:

Message: NSubstitute.Exceptions.ReceivedCallsException : Expected to receive a call matching: 
 Log<Object>(Error, 0, Test Exception, <null>, Func<Object, Exception, String>) 
Actually received no matching calls. 
Received 1 non-matching call (non-matching arguments indicated with '*' characters): 
 Log<Object>(Error, 0, *Test Exception*, <null>, Func<Object, Exception, String>)

Starting with .NET 8, Microsoft introduced the FakeLogger class to simplify unit testing for Logger!

The FakeLogger is an in-memory logger specifically designed for unit testing. It allows capturing and inspecting log messages generated by the code under test, making it easier to verify that logging is working correctly.

What are the benefits?

Features:

• Capture all log messages in memory.
• Inspect these messages to verify if the code logs correctly.
• Control log levels for more precise testing.

Benefits:

• Easy to use.
• Isolate the code under test.
• Improve the quality of unit tests.
• Avoid “reinventing the wheel,” as many solutions appear in posts with different implementations for mocking ILogger and solving this problem.

Practical Example

1- Install the package

To install the package, use the NuGet Package Manager

or simply run the following command:

dotnet add package Microsoft.Extensions.Diagnostics.Testing

Once the package is installed, let’s look at the code:

In the test class, instantiate the FakeLogger as shown in the image below.

After implementing the _logger object, note that it was passed when instantiating the StoreRepository object to act as the Logger for the class.

Now, you can write the unit tests. The importance of monitoring logs is to ensure that the correct messages are included in the return. See the example:

• Line 66: We verify that the Logger’s return is not null.
• Line 67: We check the number of items collected by the logger (messages that would be written).
• Line 68: We verify that the last log is of type “Error.”
• Line 69: We check if the last message contains the phrase stored in the CreateError variable of the StoreMessageConstants class.

Now, you know the basics of retrieving log messages and working with them to ensure your service returns the expected outputs in error cases. If you want to dive deeper into this object, check out the references at the end of this post.

Did you like the article? Click the 👏 icon and follow me to see upcoming publications! If you like to see more publications see my networks into my linktree: https://linktree.com/nizzola

How many times are we writing code and come across that old implementation of dependency injection in the application, defining interface x service, or interface x repository, as below?

Firstly, we see that the implementation is in our application’s “program.cs” (class that is accessed at startup), in addition to making it increasingly larger as your project grows, it is very difficult to validate, in addition to the dependencies that can be configured in your specific project, facilitating code analysis.

Right away, let’s create a static class within the project where the repositories are and implement an Extension Method (don’t know what it is, see my previous article) that will isolate dependency injection in a specific class for that project.

Normally I use the name “DependencyInjectorHelper” but this is not a rule, you can use any name.

In this file we will implement the injection in a method that will be an Extension Method of the “IServiceCollection” interface, which is the object where the codes were created manually!

Note that in this method we use “this” transforming it into an extension method of the “IServicesCollection” interface, so this way we can use it as it was done now in program.cs.

All of that was replaced by a single line, referencing the method we created and taking the implementation to its original project.

Program.cs is much prettier! But the class continues with the same lines, it just changed location! Compared to some projects I’ve seen, it’s already much better, but let’s make things even simpler!

We can implement these lines in our class and solve the problem.

var types = Assembly.GetExecutingAssembly().GetTypes()
    .Where(x => x.GetInterfaces().Any(i => i.Name.EndsWith("Repository")));

foreach (var type in types)
 {
        var interfaces = type.GetInterfaces();
        foreach (var inter in interfaces)
            services.AddScoped(inter, type);
 }

But what does this code do in practice? it will scan the Assembly (compiled libraries of your project) looking for classes that are declared, and in addition, classes where their interface has the suffix “Repository”.

Note that when inspecting the “types” variable it has all the classes that were described one by one in the replaced lines of code.

So, the dependency injections of this project will be mapped and the problem resolved.

Within the foreach command, it will implement the classes it mapped one by one!

But…. It’s still complex, imagine in a “solution” that I have many projects, and in each project I have to replicate these lines to scan the Assembly? I will have more lines of code in some cases than going straight to the description of each class/repository!

What is the solution? create a method that does all this and I can use it throughout the solution by executing the same logic.

So let’s create this method and use it in all other projects where I need to do dependency injection based on Interface / Class.

By creating the method above, we can eliminate all of our previous lines! Look how it turned out below:

Now we replace all those lines with a single line, triggering the created extension method! (remember to add the usage of your namespace at the top otherwise it will not be displayed associated with a “services” method.

A very important point is that our “Assembly” is passed as a parameter within the extension method, because if the method belongs to another project (as I did here) we will not have problems not finding the classes we want, as the assembly of the extension may be another!

Okay, now you can use it in any part of your solution to solve dependency injection problems, eliminating many lines and that annoying work of looking class by class and doing everything manually.

What are the benefits of scanning the Assembly?

• I don’t need to insert a line to declare this dependency every time I create a class and a repository or service (in fact, who has never run the application and realized they forgot that?).
• There is no need to remove a line in startup when removing a class and interface.

What could go wrong?

If your application have some implementation with similar names that does not comply with the interface/class dependency, if this happens, inject the conflicting items in the previous way or change the name of the classes to avoid conflicts.

This will certainly eliminate several lines from your code and you won’t need to insert a new line for each new class created.

Did you like the article? Click the 👏 icon and follow me to see upcoming publications! If you like to see more publications see my networks into my linktree: https://linktree.com/nizzola

When developing .NET applications in a containerized environment, you might encounter the error “Cannot load library libgssapi_krb5.so.2”. This message typically indicates an authentication issue when connecting your application to a SQL Server database.

Error log in the Docker container:

The libgssapi_krb5.so.2 library is associated with the Kerberos protocol, a widely used authentication mechanism in enterprise networks. When you set Trusted_Connection=true in your connection string, you’re enabling Windows Integrated Authentication, which requires this library.

Why does the error occur in Linux containers?

Linux containers do not have full support for Windows Integrated Authentication. When trying to load the libgssapi_krb5.so.2 library, the operating system cannot find it, resulting in the error.

How to resolve the issue:

The simplest solution is to disable Windows Integrated Authentication by setting Trusted_Connection=false in your connection string.

With this change, your application should work as expected, provided that your connection is based on username and password and not on Windows authentication.

Did you enjoy the article? Click the 👏 icon and follow me to stay updated on upcoming publications! See my other medium profile in portuguese with +100 articles https://marcionizzola.medium.com/.

If you’d like to see more of my work, visit my social networks on my Linktree: https://linktree.com/nizzola

References:

https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/krb5-libs-package

In this post, I will demonstrate something quite simple that will greatly facilitate the development and testing of .NET applications on your machine.

First, let’s create an API from the .NET template as a base using the following command:

dotnet new webapi -minimal — name DotnetApi

Once this is done, our application is created. Let’s navigate to the folder where it’s located and run the command dotnet run.

If everything goes well, you will see this in the console:

Now, just open your browser and type https://localhost:7232/swagger to see the following result:

Great! The API is now built according to the .NET template.

Our next step is to configure it to run in Docker. We’ll open VSCode and create a file in the folder, saving it as “Dockerfile” (with no extension).

In this script, an instance of the alpine image is mounted as the base, which will serve as the final product, and another instance is used as the build environment where the application will be built.

Then, the published content (without including the source code) is copied to the base image.

Now that it’s done and the file is saved, we go back to the command line and use the following command:

docker build . -t dotnetapi1

This command prepares the image for our application, where dotnetapi1 is the name it will have in our local Docker repository. It runs everything defined in the Dockerfile, and now all that’s left is to execute it.

docker run -p 8080:5000 -e ASPNETCORE_ENVIRONMENT=Development dotnetapi1 - name dotnetapi1

By executing this command, Docker will actually run the image, generating a specific container for it, which will respond on port 8080. Additionally, I set the ASPNETCORE_ENVIRONMENT variable to “Development” because Swagger is configured by default to run only in a Development environment.

Now, just open your browser and test using localhost:8080.

It works!! But what if I want to have another container running? Is that possible?

docker run -p 8081:5000 -e ASPNETCORE_ENVIRONMENT=Development dotnetapi1 - name dotnetapi2

The result is here: running on different ports, we have two containers of the same application!

If we look at the Docker interface now, we see two containers running the same application simultaneously! But how can we identify each one?

Each container in Docker is displayed with a unique identifier:

Let’s edit our application to retrieve the machine name where it’s running and display it in Swagger!

To do this, we’ll edit our program.cs to include the OpenApi implementation.

We need to rebuild our container by creating the image again and then running docker run once more.

As a result, we can now see that the machine name is displayed in Swagger. Additionally, we can modify our application so that the logs include the machine name to help identify the source of the logs.

Did you enjoy the article? Click the 👏 icon and follow me to stay updated on upcoming publications! See my other medium profile in portuguese with +100 articles https://marcionizzola.medium.com/.

If you’d like to see more of my work, visit my social networks on my Linktree: https://linktree.com/nizzola

Project repository: https://github.com/NIZZOLA/DotNetApiWithDocker

Who has never encountered this error when returning a response from the Entity Framework directly to an API and gets this message:

An unhandled exception occurred while processing the request.

JsonException: A possible object cycle was detected.

Before start, remeber to click the 👏 icon and follow me to stay updated on upcoming publications, it´s very important !

This can either be due to a cycle or if the object depth is larger than the maximum allowed depth of 32. Consider using ReferenceHandler.Preserve on JsonSerializerOptions to support cycles. …..

System.Text.Json.ThrowHelper.ThrowJsonException_SerializerCycleDetected(int maxDepth).

Whenever you go through this, it is a simple and easy-to-solve problem, because when we map an object in the Entity Framework, it has references to the “parent” object in the relationship in a cyclical way, where again the “parent” will have the “ son” endlessly.

This is due to the mapping of entities and normally occurs when we use the “Include” command to bring an entity that is associated with another, as below:

var result = _context.Cliente.Include(a => a.Enderecos).ToList();

This reminds me of a Matrioska (Russian doll that fits inside each other almost infinitely).

We have different solutions for each case:

If you are still using Controllers and your application is above .NET 3, just put this in the initialization of your application:

services.AddControllers().AddJsonOptions(x =>
   x.JsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve);

If you are using Minimal Api, insert the code below when starting the application (program.cs).

builder.Services.Configure<Microsoft.AspNetCore.Http.Json.JsonOptions>(options => options.SerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles);

Now, if you are still mapping using Newtonsoft.Json, the solution would be like this:

services.AddControllers().AddNewtonsoftJson(x => 
 x.SerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore);

Did you enjoy the article? Click the 👏 icon and follow me to stay updated on upcoming publications! See my other medium profile in portuguese with +100 articles https://marcionizzola.medium.com/.

If you’d like to see more of my work, visit my social networks on my Linktree: https://linktree.com/nizzola

Many times we need to construct console applications who need to use Dependency Injection, but console template from .NET is very simple and do not implement this by default.

Before start, remeber to click the 👏 icon and follow me to stay updated on upcoming publications, it´s very important !

Here, I will show you how to implement dependency injection elegantly using extension methods.

See this example of my “program.cs” :

In line 5, we have a instance of variable “environmentName” to be used to get configuration file after.

In line 7, the “configuration” variable is created to get our settings from “appsettings.json” and “appsettings” with environment name variable, like “appsettings.development.json” or “appsettings.stage.json”.

In line 13, we instantiate a variable ‘services’ with a ‘ServiceCollection’ instance. It’s used later to insert and retrieve our services via Dependency Injection.

In line 14, we call method named “ConfigureNizzolaAzure” on the “services” variable. What is that? It´s an extension method created to configure depencency injection outside “program.cs”.

The “cherry on the top” is this method; It´s an extension method who implement dependency injection in a more elegant way, as explained below:

Details:

• It’s a static class and method because we use the ‘this’ parameter to create an extension method for ‘IServiceCollection’. This allows your variables in ‘program.cs’ to use this method during application startup (as seen in line 7 of program.cs).
• we receive “IConfigurationRoot” as a method parameter named “configuration” to be used in line 11.
• in line 11, we get “section” from “appsettings” using configuration variable, and inject into “ServiceCollection”, it´s important to use “NizzolaAzureOptions” class when we need to inject into services via Dependency Injection. (as the same way of my old post ).
• in line 13, we prepare dependency injection of services, assign interface “INizzolaAzureBlobService” and class “NizzolaAzureBlobService”, in a singleton lifecycle.

Now it´s ok, when you need to use dependency injection, in “program.cs “ you only need to get instance from “ServiceCollection”, this command in line 17 do this:

var blobService = serviceProvider.GetService<INizzolaAzureBlobService>();

Afterward, you only need to call methods on the ‘blobService’ as shown in line 21 of program.cs:

await blobService.UploadFile("images\\8meetupItu.jpg");

Can we improve even more? Yes, wait for the next posts to see other examples of code improvements.
“Better than writing code is deleting code!” Unknown author

Important 👏

Did you enjoy the article? Click the 👏 icon and follow me to stay updated on upcoming publications! If you’d like to see more of my work, visit my social networks on my Linktree: https://linktree.com/nizzola

References:

• Options pattern in ASP.NET Core
• IServiceCollection Interface (Microsoft.Extensions.DependencyInjection)
• Extension Methods - C# Programming Guide - C#