Forem: RzR

Handle data set pagination with `PagedListResult`

RzR — Thu, 05 Feb 2026 19:25:11 +0000

Overview

PagedListResult is a focused .NET library that standardizes server‑side pagination, sorting, searching, and filtering into a clear request → execution → result pipeline. The repository is intentionally opinionated: instead of exposing many small helpers, it defines strong contracts (request and result models) and a set of query extensions that apply those contracts to IQueryable<T> sources.

The primary goal of the project is to eliminate repetitive pagination logic in APIs and application services, while keeping the query behavior explicit, testable, and extensible.

Design Philosophy

The repository follows several consistent design principles that are visible across all projects:

Contract‑first pagination – Pagination is driven by a request model rather than ad‑hoc parameters.
Queryable‑centric execution – All operations are applied to IQueryable<T>, allowing deferred execution and provider‑level optimizations.
Separation of concerns – Request/response models, query logic, and common helpers are separated into distinct projects.
API‑oriented output – The result model includes metadata required by front‑end grids and consumers, not just the data subset.

Repository Structure

The solution is split into multiple projects, each with a strictly scoped responsibility. This separation is not cosmetic; it directly reflects how pagination concerns are decomposed and enforced across the library.

1. PagedListResult.DataModels (Core Contract Layer)

This project is the foundation of the entire solution. Every other project depends on it, and it intentionally contains no query execution logic. Its sole purpose is to define stable, serializable contracts that describe what the consumer wants and what the system returns.

Architectural Role

Acts as a boundary layer between clients (API/UI) and query execution
Ensures pagination behavior is explicit and versionable
Makes pagination requests portable across services

This design allows the same request model to be reused in:

ASP.NET Core controllers
Application services
Background jobs
Integration tests

Key Types and Responsibilities

PagedRequest

The PagedRequest type is the central aggregation root of pagination input. Rather than scattering parameters, it consolidates all query intent into a single object.

Core responsibilities:

Page index normalization
Page size definition
Optional ordering definition
Optional search definition
Optional filter collection

The model is intentionally permissive: most properties are optional, allowing minimal or advanced usage with the same contract.

Paging Semantics

Paging is expressed in logical terms, not execution terms:

Page represents the requested page index
PageSize represents the logical size of the page

No assumptions are made about storage or transport. Execution layers decide how to translate these into Skip / Take operations.

OrderOptions

OrderOptions defines ordering intent without binding to LINQ or database specifics.

Key characteristics:

Property name is expressed as a string
Direction is represented as a semantic enum or value
Designed to be validated before execution

This allows clients to control ordering while keeping execution safe and predictable.

SearchOptions

Search is modeled explicitly rather than as a generic filter.

Responsibilities:

Store the search term
Define whether the search applies to all text fields
Enable consistent interpretation of search intent

By isolating search into its own model, the library avoids overloading filters with responsibilities they are not suited for.

Filter Models

Filtering is expressed through a structured hierarchy rather than ad-hoc predicates.

Typical filter elements include:

Target property name
Condition operator (equality, range, containment, etc.)
One or more comparison values
AND or OR comparation apply between values/filters
Dependence between filters

This structure enables:

Validation before execution
Deterministic expression generation
Consistent behavior across endpoints

PagedResult

PagedResult<T> is the authoritative output contract of the library.

It contains:

The paged response collection
Paging metadata (page, page size, page count)
Total row count
Execution diagnostics

Importantly, the result is self-describing: consumers do not need to recompute or infer paging state.

ExecutionDetails

Execution diagnostics are modeled explicitly rather than logged implicitly.

This enables:

Performance analysis at the API boundary
Transparent reporting to consumers
Easier debugging in distributed systems

2. PagedListResult.Common (Query Interpretation Layer)

This project translates intent into executable logic.

Its responsibility is to convert DataModel contracts into expression trees that can be applied to IQueryable<T> without knowing the underlying provider.

Core Responsibilities

Validate property access at runtime
Build expression trees for:
- Filters
- Search
- Ordering
Combine multiple expressions deterministically

Expression-Driven Design

Rather than building queries imperatively, the library constructs expression trees. This allows:

Provider-level optimization
Deferred execution
Compatibility with LINQ providers

Each query concern (filter, search, order) is handled independently and then composed.

3. PagedListResult (Execution & Integration Layer)

This project is the behavioral core of the solution. While DataModels defines what should happen and Common defines how intent is translated, PagedListResult defines when and in what order everything is executed.

It is also the only project that consumers typically reference directly.

Public API Surface

The project exposes a minimal but powerful public surface:

Extension methods over IQueryable<T>
Strongly typed pagination execution returning PagedResult<T>

This design deliberately avoids:

Base repository abstractions
Framework‑specific dependencies at the API boundary
Hidden execution side effects

Consumers remain in full control of when queries are materialized.

Extension Method Architecture

Pagination is implemented entirely via extension methods rather than services or static helpers.

Key implications:

Pagination composes naturally with LINQ
No dependency injection is required
Domain entities remain untouched

A typical execution entry point:

query.GetPagedAsync(pagedRequest);
query.GetPagedWithFiltersAsync(pagedRequest);
query.GetPagedWithMainFiltersAsync(pagedRequest);

Internally, this single call coordinates the entire pipeline.

Execution Orchestration Responsibilities

The PagedListResult project does not build expressions itself. Instead, it orchestrates execution by delegating responsibilities in a strict order.

Its responsibilities include:

Guard‑clause validation of the request
Delegation of search, filter, and order logic
Pagination window calculation
Execution diagnostics capture
Final result assembly

This ensures that query semantics remain centralized and predictable.

Ordering Strategy Enforcement

One subtle but critical responsibility of this layer is ordering enforcement.

Stable pagination requires deterministic ordering. The execution layer ensures that:

Explicit ordering is applied when provided
A fallback strategy exists when ordering is missing
Ordering is applied before pagination

Without this enforcement, page boundaries could shift between executions.

Row Count Evaluation

Row count is evaluated before pagination is applied.

This design decision ensures:

Accurate RowCount
Correct PageCount
Independence from page size or index

The execution layer explicitly separates:

Total dataset size
Paged window size

This distinction is critical for client‑side pagination controls.

Pagination Window Calculation

The execution layer translates logical paging intent into execution behavior:

Calculates skip offset from page index and page size
Applies Skip and Take only after all query conditions

This guarantees that pagination is applied to the final filtered and ordered dataset.

ExecutionDetails Population

Execution diagnostics are captured as part of the core workflow.

Typical captured details include:

Start and end timestamps
Total execution duration

By embedding diagnostics in the result rather than logging implicitly, the library enables:

Transparent performance reporting
API‑level observability
Easier troubleshooting without log access

Result Assembly

The final step is deterministic result construction.

The execution layer assembles:

Materialized response data
Paging metadata
Execution diagnostics

The resulting PagedResult<T> is immediately consumable by API clients without additional transformation.

Detailed Pagination Execution Pipeline

The execution pipeline is deterministic and ordered to avoid ambiguity.

Request Validation

Page boundaries
Page size constraints
Property existence for filters and ordering

Search Application

Text-based expressions generated first
Applied before filters to reduce dataset early

Filter Application

Structured conditions translated into expressions
Combined using logical AND or OR semantics

Ordering Application

Explicit ordering or fallback strategy
Ensures stable pagination

Row Count Evaluation

Executed before paging
Represents total matching dataset size

Pagination Application

Skip and Take applied last

Result Materialization

Execution timing captured
PagedResult<T> populated

Structured Result Serialization: JSON and XML Support

One important capability of the PagedListResult project that deserves explicit attention is its built‑in support for result serialization targeting JSON and XML consumers.

This functionality is not an afterthought; it is reflected directly in the source code and aligns with the library’s API‑first design.

Why Serialization Is a First‑Class Concern

The library assumes that paged results are most often:

Returned from REST APIs
Consumed by heterogeneous clients
Persisted or logged in structured formats

For that reason, the result model (PagedResult<T>) and its related metadata types are designed to be:

Fully serializable
Deterministic in structure
Independent of execution context

This makes the result suitable for both JSON‑based APIs and XML‑based integrations without custom mapping layers.

JSON Result Shape

From the source perspective, the JSON representation is a direct projection of the result contract:

Paging metadata is exposed as top‑level fields
Execution details are explicitly represented
The response collection is serialized as a structured array

Because the library avoids custom converters or runtime mutation, the JSON output remains:

Stable across executions
Predictable for front‑end grids
Easy to version

This is particularly important for client‑side pagination components that depend on fixed property names.

XML Result Support

The repository also supports XML‑friendly result structures.

Key characteristics visible in the source:

Result and metadata models are designed with XML serialization compatibility in mind
No reliance on JSON‑only attributes or behaviors
Clean hierarchical structure suitable for XML consumers

This enables scenarios such as:

Legacy system integrations
SOAP‑adjacent services
Inter‑service communication where XML is still required

The same PagedResult<T> contract can be serialized to XML without transformation, preserving paging semantics and metadata.

Search Behavior and Serialization Alignment

Search functionality (including text search across multiple fields) is intentionally decoupled from serialization concerns.

However, the results of search operations are fully reflected in the serialized output:

RowCount represents the count after search and filters
PageCount reflects the searched dataset
The response collection contains only matching items

This guarantees that JSON or XML consumers always receive a consistent and truthful representation of the executed query.

Design Implications

By designing serialization‑friendly result contracts, the library achieves:

Zero transformation overhead at API boundaries
Reduced controller/service boilerplate
Clear separation between execution logic and representation

This reinforces the repository’s broader architectural theme: explicit contracts over implicit behavior.

Summary

PagedListResult is not only a pagination and query‑execution library; it is also a transport‑ready result framework.

Its built‑in alignment with JSON and XML serialization ensures that paged results can move safely and consistently across system boundaries, making it especially suitable for real‑world API and integration scenarios.

For teams working with mixed client ecosystems or strict API contracts, this aspect of the library is a critical—and often underappreciated—strength.

PagedListResult is not a simple paging helper; it is a contract-driven pagination framework designed for service-oriented .NET applications.

By separating:

intent (DataModels)
interpretation (Common)
execution (Core)

…the repository achieves a high level of clarity, safety, and extensibility.

For teams building APIs that require consistent, transparent, and extensible pagination behavior, this project provides a strong and thoughtfully designed foundation.

PagedListResult is a strongly structured pagination solution for .NET developers who want:

Explicit pagination contracts
Centralized query logic
Rich response metadata
Minimal repetition across endpoints

The repository demonstrates a clean separation between data contracts, query infrastructure, and execution logic, making it both approachable for consumers and extensible for advanced scenarios.

For developers building serious, data‑driven APIs, this repository provides a solid and opinionated foundation for pagination done right.

Repository: https://github.com/I-RzR-I/PagedListResult

`XmlFluentValidator`: Code-First XML Validation That Stays Close to Your Rules

RzR — Mon, 12 Jan 2026 18:17:08 +0000

XmlFluentValidator: Code-First XML Validation That Stays Close to Your Rules

XML is still alive and is almost everywhere used: configuration files, integration contracts, legacy systems, and enterprise messaging. Yet validating XML in a clean, maintainable, and expressive way remains a challenge for a part of developers.

A lot of teams end up choosing between:

Hand-written XSDs that are verbose, fragile, and disconnected from business logic;
Imperative validation code scattered across internal services, quite difficult to reuse or document.

XmlFluentValidator proposes another approach:
define XML validation rules fluently in C#, validate at runtime, and generate schemas and documentation from the same source of truth (source code).

The Problem/Difficulties with Traditional XML Validation

XSD has its own power, but it comes with real trade-offs:

Low readability and poor discoverability;
Limited expressiveness for cross-element or computed rules;
Hard to evolve alongside application logic;
No(or very poor) natural place for business-level validation semantics;

On the other hand, pure runtime validation often results in:

Custom XPath logic duplicated across projects;
No formal schema to share with consumers;
Inconsistent validation behavior between runtime and contracts;

XmlFluentValidator can help you to close a part of this gap.

What XmlFluentValidator Is

XmlFluentValidator is a .NET Standard 2.0 library that allows:

Define XML validation rules using a fluent, strongly-typed C# API;
Validate XML documents at runtime with structured error output;
Set documentation, severity, and messages to rules;
Combine schema validation with custom runtime logic
Generate XSD schemas from rules (supported and evolving)

It treats validation rules as first-class code artifacts, not static XML files.

Core Design Principles

1. The Code Is the Source of Truth

Validation rules live in C#, alongside your domain logic.
No duplication between schema files and runtime validation.

2. Fluent, Intent-Driven API

Rules read like requirements, not infrastructure:

What element is required?
What constraints apply?
Why does this rule exist?

3. Runtime + Schema Compatibility

Rules are designed to map cleanly to XSD constructs where possible, while still allowing runtime-only logic when necessary.

Defining Validation Rules

At the core of the library is a fluent builder that targets paths, elements, and attributes.

Element Rules

var validator = new XmlFluentValidator()
    .ForPath("/order/id")
        .WithElementRequired("Order ID is required")
        .WithElementMatchesRegex(@"^\d+$", "Order ID must be numeric")
        .Done()
    .ForPath("/order/total")
        .WithElementInRange(0, 10000, true, "Total must be between 0 and 10000")
        .Done();

This expresses clearly:

The element must exist;
The value must follow a specific format;
The value must be within a valid numeric range;

No XSD syntax. No XPath boilerplate.

Attribute Validation

Attributes are validated explicitly and consistently:

validator
    .ForPath("/order/items/item")
        .WithAttributeRequired("sku", "SKU is mandatory")
        .WithAttributeMatchesRegex("sku", @"^[A-Z0-9\-]+$")
        .WithAttributeInRange("quantity", 1, 100, true)
        .Done();

This avoids the common XSD problem where attribute rules are hard to read or scattered.

Cardinality, Length, and Uniqueness

The API supports common structural constraints:

Element existence (required / optional);
Maximum occurrences;
Value length (min, max, exact);
Uniqueness across sibling nodes;
Data type enforcement;
Nullable (xs:nillable) control;

All of these can also be documented and messaged directly in code.

Custom and Global Rules

Some rules cannot be expressed in XSD at all.

For example: cross-element logic, computed totals, or document-wide constraints.

XmlFluentValidator supports global rules:

validator.GlobalRule(doc =>
{
    var items = doc.XPathSelectElements("/order/items/item");
    return items.Any();
}, "Order must contain at least one item");

These rules:

Run at runtime;
Participate in the same validation pipeline;
Produce structured error messages;
Can coexist with schema validation;

This is one of the strongest differentiators of the library.

Validation Execution and Results

Validation is executed explicitly:

var result = validator.Validate(xDocument);

if (!result.IsValid)
{
    foreach (var error in result.Errors)
    {
        Console.WriteLine($"{error.Path}: {error.Message}");
    }
}

Each validation error includes:

The XML path;
The violated rule;
The configured message;
Severity metadata;

This makes the output suitable for:

APIs
Logging
Automated tests

XSD Schema Generation

A key goal of XmlFluentValidator is schema generation from fluent validation rules.

Rules such as:

required elements;
data types;
ranges;
enumerations;
documentation annotations;

can be emitted into an XSD representation.

This allows:

Share contracts with external systems;
Keep schemas aligned with runtime validation;
Avoid maintaining two parallel validation models;

The feature is actively evolving and designed into the API from the start.

How It Fits into Real Systems

XmlFluentValidator is especially useful when:

XML validation rules evolve frequently;
Business logic must be enforced beyond XSD capabilities;
Validation must run dynamically at runtime;
Schemas still need to be shared or documented;
Validation logic belongs with application code, not static files;

Typical use cases include:

Integration gateways;
Configuration validation;
ETL pipelines;
Legacy XML modernization;
Domain-specific XML formats;

Final Thoughts

XmlFluentValidator is not trying to replace XSD.
It aims to make XML validation more expressive, maintainable, and aligned with the way modern .NET developers think. **

If you also believe:

validation rules should read like business rules;
code should be the primary source of truth;
and schemas should be generated, not hand-crafted;

Then, XmlFluentValidator is worth your attention.

🔗 Repository: https://github.com/I-RzR-I/XmlFluentValidator

Avoid "String or binary data would be truncated" or how to save safe strings.

RzR — Fri, 05 Sep 2025 05:58:20 +0000

In the current reality almost everyone and everyday interact with data and executing base CRUD operations. The most common exception met is:

“String or binary data would be truncated” or in other words…

“The maximum allowed field/property length was exceeded and the operation can’t be finished”.

This error happens when the length of string data exceeds the maximum length defined for a column—resulting in disruptive runtime failures and tedious debugging. Manually trimming strings or validating their lengths can be cumbersome, especially in projects with numerous entities or frequent changes.

That is where EntityMaxLengthTrim comes in.

EntityMaxLengthTrim is a lightweight .NET library designed to automate the truncation of string values based on their maximum length constraints. It inspects entity properties adorned with standard data-annotation attributes—such as MaxLength, StringLength or MaxAllowedLength —and a custom attribute for extra flexibility. The library trims overly long inputs before they reach the database, helping you avoid runtime exceptions while preserving code cleanliness and maintainability.

Why This Matters

The value of a library like EntityMaxLengthTrim lies in safety and consistency. By applying length rules at the entity level, you ensure that all string values conform to your schema before they reach the database. This reduces runtime surprises, prevents data loss, and keeps your codebase focused on business rules instead of plumbing.

How EntityMaxLengthTrim Works

At its core, EntityMaxLengthTrim relies on interception and reflection to ensure your entity strings always conform to the maximum allowed length before ORM attempts to persist them. Let us unpack the mechanics.

Examples:

Example 1:

So from the beginning first action is to define the data model.

public class FooModel
{
    public Guid Id { get; set; }

    public string Name { get; set; }

    public string FullName { get; set; }

    public string Description { get; set; }
}

The next step is to decorate every string property which you would like to apply the maximum length rule with one of the following attribute: MaxLength, StringLength or MaxAllowedLength.

public class FooModel
{
    public Guid Id { get; set; }

    [MaxLength(25)]
    public string Name { get; set; }

    [StringLength(120)]
    public string FullName { get; set; }

    [MaxAllowedLength(512)]
    public string Description { get; set; }
}

One of the last step is to call the methods which will make the magic.

var parsedData = sourceEntityData.ToSafeStoreStrings();

Example 2:

For this example, the first step is the same as in Example 1, we need to define the data model.

public class FooModel
{
    public Guid Id { get; set; }

    public string Name { get; set; }

    public string FullName { get; set; }

    public string Description { get; set; }
}

The next step we nedd to execute is to inheritance a base class EntityPropChangeEventBase which implement the interface INotifyPropertyChanged and event PropertyChangedEventHandler. In the data model class we need to convert default property to property with backing field

As result we will see:

public class FooModel : EntityPropChangeEventBase
{
    private string _name;
    private string _fullName;
    private string _description;

    public Guid Id Type { get; set; }

    [MaxLength(25)]
    public string Name
    {
        get => _name;
        set => _name = value;
    }

    [StringLength(120)]
    public string FullName
    {
        get => _fullName;
        set => _fullName = value;
    }

    [MaxAllowedLength(512)]
    public string Description
    {
        get => _description;
        set => _description = value;
    }
}

And the last step is to implement functionalities from base class

public class FooModel : EntityPropChangeEventBase
{
    private string _name;
    private string _fullName;
    private string _description;

    public Guid Id { get; set; }

    [MaxLength(25)]
    public string Name
    {
        get => _name;
        set
        {
            if (_name == value) return;
            _name = value;
            OnPropertyChanged(this, nameof(Name));
        }
    }

    [StringLength(120)]
    public string FullName
    {
        get => _fullName;
        set
        {
            if (_fullName == value) return;
            _fullName = value;
            OnPropertyChanged(this, nameof(FullName));
        }
    }

    [MaxAllowedLength(512)]
    public string Description
    {
        get => _description;
        set
        {
            if (_description == value) return;
            _description = value;
            OnPropertyChanged(this, nameof(Description));
        }
    }
}

So this is the result, but when we take a look in the result class first think is that: is too much code for the set property.
For this case exist another method SetContent which will simplify the code:

public class FooModel : EntityPropChangeEventBase
{
    private string _name;
    private string _fullName;
    private string _description;

    public Guid Id { get; set; }

    [MaxLength(25)]
    public string Name
    {
        get => _name;
        set => SetContent(this, nameof(Name), ref _name, ref value);
    }

    [StringLength(120)]
    public string FullName
    {
        get => _fullName;
        set => SetContent(this, nameof(FullName), ref _fullName, ref value);
    }

    public string Description
    {
        get => _description;
        set => SetContent(this, nameof(Description), ref _description, ref value, 512);
    }
}

If we take a look at the last code example, we can see that in the two cases was used the rule for maximum text length was used as an attribute, but in one case, the length was passed as an input parameter for SetContent method.

As a simple conclusion, the SetContent can be used in dependency on the code environment. The next time this data model is supplied with data, the maximum length rule will be triggered.

These two examples are not all the use cases of when and how it can be used. For all publicly available methods, you can check the repository in GitHub; it all depends on the application's business logic and core environment, and requirements.

The repository link:

I-RzR-I / EntityMaxLengthTrim

One important thing about this repository, you have the possibility to avoid database exceptions related to exceeding the limit of the maximum allowed length of the string type columns. To specify the maximum allowed string length you can use data annotation attributes predefined in `System.ComponentModel.DataAnnotations` or a new custom attribute.

Note This repository is developed for .netstandard1.5+ and net framework 4.5

One important thing about this repository is that you can truncate input string in the fields/properties at the maximum allowed length from DB. To specify the maximum allowed string length you can use data annotation attributes predefined in System.ComponentModel.DataAnnotations or a new custom attribute.

The maximum allowed length will be searched in the attributes(you may use one of these):

MaxLengthAttribute -> ([MaxLength(x)]);
StringLengthAttribute -> ([StringLength(x)]);
MaxAllowedLengthAttribute -> ([MaxAllowedLength(x)]).

To get acquainted with a more detailed description, please check the content table at the first point.

Once you use this repository, you have the possibility to avoid database exceptions related to exceeding the limit of the maximum allowed length and the string type columns.

No additional components or packs are required for use. So, it only needs to be added/installed in the project…

View on GitHub

MediatRItemExtension - Visual Studio(2019,2022) extension made by developer for developers

RzR — Tue, 02 Sep 2025 19:12:27 +0000

This Visual Studio extension is designed to streamline the development process when working with the MediatR and FluentValidation NuGet packages.

FluentValidation is a .NET library for building strongly typed, expressive and reusable validation rules for objects, particularly model classes.

MediatR is a lightweight, in-process messaging library for .NET that implements the Mediator design pattern. It decouples the communication between objects, enabling a clean, maintainable, and scalable architecture by reducing direct dependencies between components.

This extension automates the creation of essential classes, such as Request (Command/Query object), Handler, and Validator, ensuring consistency and reducing manual effort. By eliminating the repetitive task of setting up these boilerplate components, the extension enhances productivity, allowing developers to allocate more time to higher-priority tasks from the backlog or active sprint.

From the box, are available functionalities are:

Save all classes in one file;
Create a file for each class;
Add import references (for MediatR and FluentValidation);
Select how the request will be executed Sync or Async;
Select which type of operation you want to create;
Specify the name of the folder/file;
Use one name for the folder/file where information will be stored;
Select an option if you want to add IStringLocalizer(Microsoft.Extensions.Localization) to Validator or/and to the Handler;
Specify any base class that will be added to the operation class (Query, Command, Notification);
Declare the operation inheritance class;
Declare the handler inheritance class.

You can install extensions from the VS marketplace (https://marketplace.visualstudio.com/publishers/RzR).

After installing the VS extension MediatRItemExtension.V2K19 or MediatRItemExtension.V2K22 (depending on which Visual Studio version you have installed).

Trigger/activate extension can be thought of as a shortcut or from the project/folder context menu:

Select a project or a folder from the solution:

-> SHIFT + INSERT + M;

-> Right click and select MediatR Items Creation.

How the interaction window is shown

Repository:

I-RzR-I / MediatRItemExtension

This is a relatively simple VS extension that allows you to create necessary classes when u use `MediatR` with `FluentValidation` nuget packages. Also, allows to save time and redirect it to more important tasks that are on the board or in the queue.

Name	Details
`MediatRItemExtensionV2K19`	Extension for Visual Studio 2019
`MediatRItemExtensionV2K22`	Extension for Visual Studio 2022

This is a relatively simple VS extension that allows you to create necessary classes when u use MediatR with FluentValidation nuget packages. Also, allows to save time and redirect it to more important tasks that are on the board or in the queue.

From the box are available functionalities as:

Save all classes in one file;
Create a file for each class;
Add import references (for MediatR and FluentValidation);
Select how the request will be executed Sync or Async;
Select which type of operation you want to create;
Specify the name of the folder/file;
Use one name for the folder/file where will be stored information;
Select option if you want to add IStringLocalizer to Validator or/and to the Handler;
Specify any base class which will be added to the operation class (Query…

View on GitHub

Generating a version and history of code changes with automation on Azure DevOps

RzR — Tue, 02 Sep 2025 07:26:39 +0000

Every person, as an application developer, a manager, or another member of the development team, but also as a customer of a final product, is interested in being traceable throughout the project/product life cycle.

To make it clear, we can define some major points as to why an application version is necessary:

Tracking changes and functionalities;
Handling errors and debugging the code;
Specifying compatibility and dependencies;
Communicating with the user/customer;
Preparing update packages;
Periodic security updates;
Product support and maintenance;

In the given context, when I try to say traceability, I mean that every change made, regardless of its purpose, must be associated with a product version. Thus, every adjustment can be tracked. A code or application error can be identified in different situations, significantly reducing the time and resources required for an investigation or debugging of the code, drawing attention and resources only in a narrow direction. Also, application versioning is beneficial when communicating with the customer/user of the product about a new functionality introduced in version X, but surely there are still many reasons why it is beneficial and why it must be implemented in every project.

Next, I would like to present an implementation method that would be the logic followed when generating the version and when executing changes in the code according to the commits. For the demonstration, "PowerShell", "YAML" and a C# project will be used.

First, we need to define how to generate a version. For the given example, w.x.y.z will be used, where:

w -> major version, set manually;
x -> the current year will be taken at execution
y -> the current month will be taken at execution;
z -> it will be incremented by one unit each time at execution and will be reset at the beginning of each month.

Example: w.x.y.z -> 1.25.3.1, 1.25.3.2, ..., 1.25.4.1

Once the generation algorithm is generally defined, a script must be written that will execute it each time and will take into account the current version defined in the project.

The project used is one written in C#, the version will be defined in the predefined file "AssemblyInfo.cs"; we will create another file, "GeneralAssemblyInfo.cs" to be able to use it within a solution for all projects and to have a single version reflected.

The data about the current version is stored in the attributes: "AssemblyVersion", "AssemblyFileVersion" and "AssemblyInformationalVersion". Following the generation of a new version, the data should be updated in this file and in the specified attributes.

The file "generate-new-version.ps1"(https://github.com/I-RzR-I/AutoAzureDevOpsGenerateChangeLogAndVersion/blob/main/build/generate-new-version.ps1) contains the execution code. From the current point, you can run scripts with supplying the required parameters and get a new version of the application. To enhance comfort during usage, you can create a bat file and run it every time you need it and forget about the required parameters or the value that needs to be added to a parameter.

What about a changelog history that is based on code commits?
Writing relevant, clear, and well-structured commit messages is crucial for maintaining organized and understandable project history. Every commit message helps team members understand the purpose of change added to the project, so it can provide base context information without the necessity to open code and examine it. A clear commit can help develop teams to track when some issue appear or was introduced, making code debugging easier, efficient, and faster.

To make a change log from the commits, we need to define the logic and what we need from the changelog. In the current example, the following structure is defined:

# v0.0.0.0 [DevOps ChangeLogVersion](mailto:commit@domain.com)

* [658f59b] (User) -> Update generate changelog pipeline

* [80c37a2] (User) -> Update solution build pipeline

On generating the commit history, I’ll add more logic to simplify the number of required actions to execute the code.

Creating the script file, I’ll also use the "PoweShell" script and define the following methods:

“Get-CommitMessage” – Get the commit message added by the user;
“Get-CommitHash” – Get commit hash;
“Add-ChangeLog” – Add the commit data to changelog file.

Add input parameters to make a more customized request, like application name, generate new application version, auto pull the latest version of source/main branch, auto commit and push data (modification) to origin, source branch name, destination branch name, and current execution path (solution path). The full code and execution logic are in the “generate-change-log.ps1”(https://github.com/I-RzR-I/AutoAzureDevOpsGenerateChangeLogAndVersion/blob/main/build/generate-change-log.ps1) file.

In case when you are the only developer or have a small development team (2-3 persons), you can execute the script on your local machine and never mind about some problems. However, every time to open the console and write parameters, it is annoying and boring, so to use efficient time, just create a bat file and apply all parameters there.

In part with automation is used “Azure DevOps”. Through automation, I try to make known the chosen method for the given case. It will try to automate the generation of a new version and the generation of the history, but also the solution build.

For both cases, two files will be created: “run_gen_changelog_version.yaml” and “run_solution_build.yaml”. These two files will be integrated to be executed before merging the new feature branch and the stable 'develop' branch.

“run_gen_changelog_version.yaml” – generate new application version, commit history in changelog;

“run_solution_build.yaml” – build the solution;

Integration will be achieved by implementing policies and blocking completion pull requests.

Azure DevOps configuration

Pipeline configuration

Select your repository, for me, it is “GenerateChangeLogAndVersion”

Add (import) previously specified yaml file to pipelines and set the pipeline variables. For “run_gen_changelog_version.yaml”: “commit_user_email” and “repository_full_path”. For “run_solution_build.yaml”, there are two local variables that must be modified “solutionPath” and “sdkVersion”.

Branch build service configuration

Select your repository, for me is “GenerateChangeLogAndVersion”
Access repository branches
Select the position “All branches”, then go to “Security”, and select “… Build Service” (for me is “GenerateChangeLogAndVersion Build Service”), then for “Contribute” pick “Allow” option.

Branch policy configuration

Select your repository, for me is “GenerateChangeLogAndVersion”
Access repository branches
Select the “develop” branch and go to “Policies”.
Here starts “Build Validation” and “Status Checks” configuration. See the images

Build Validation Configuration

Status Checks Configuration

As result

After all configurations on the pull request are initiated, all policies will be applied and require user action.

After “Queue”, the script with the version generate will run and push new changes in the current PR.

Changelog and version result:

Source code:

I-RzR-I / AutoAzureDevOpsGenerateChangeLogAndVersion

Generating a version and history of code changes with automation on Azure DevOps

Generating a version and history of code changes with automation on Azure DevOps.

To make it clear, we can define some major points as to why an application version is necessary:

Tracking changes and functionalities;
Handling errors and debugging the code;
Specifying compatibility and dependencies;
Communicating with the user/customer;
Preparing update packages;
Periodic security updates;
Product support and maintenance;

View on GitHub

Web API `Result` or `AggregatedGenericResultMessage.Web` how it works.

RzR — Tue, 02 Sep 2025 06:52:36 +0000

Web Result is based on the simple implementation of Result(AggregatedGenericResultMessage). The entire implementation is like a wrapper to be used within a web project, which will be able to an easy-to-understand, structured, and filtered response as needed to be returned to the client.

Everything can start by inheriting the methods from ResultBaseApiController which returns a response of the type IActionResult and as HTTP codes 200, 204, or 400. IResult or IResult<T> is used as an input parameter, thus checking which code the response should be returned to the client.

Another way of using it is by using methods that extend the I/Result and I/Result<T> functionalities from the ToActionResult class, but which as a final result return ActionResult via ObjectResult, thus diversifying the way of use and offering opportunities and levers for easy integration into other solutions.

GitHub source:

I-RzR-I / AggregatedGenericResultMessage-Web

This library is an aggregate of some extensions to use more comfortable `Result lib`. In other words, transform from `Result` to `IActionResult`.

Note This repository is developed using .netstandard2.1.

The important thing about this repository is to offer the possibility to manage and organize your result/response from infrastructure to user/controller, as the principal repository around which are built all extensions is AggregatedGenericResultMessage.

In case you wish to use it in your project, u can install the package from nuget.org or specify what version you want:

Install-Package AggregatedGenericResultMessage.Web -Version x.x.x.x

Content

View on GitHub

Refer links:

ResultBaseApiController: https://github.com/I-RzR-I/AggregatedGenericResultMessage-Web/blob/main/src/AggregatedGenericResultMessage.Web/ResultBaseApiController.c

ToActionResult: https://github.com/I-RzR-I/AggregatedGenericResultMessage-Web/tree/main/src/AggregatedGenericResultMessage.Web/Extensions/ActionResult

What is the `Result` ( AggregatedGenericResultMessage) and how does it work?

RzR — Tue, 02 Sep 2025 06:44:40 +0000

In this section, I would like to explain what it is for and how it can work.

To begin with, it would be necessary to specify that such an idea has been around since I started my career as a developer. Surely everyone has faced a situation when during the execution of a flow, some errors or exceptions occur that need to be handled and a response returned that is understandable to each participant in the execution flow. The main reason behind the implementation was the principle that no method implemented in the code should throw an exception, the only and most correct approach is to handle it and return it in a relatively easily understood form.

Respectively, this repository/package aims to provide the possibility to manage the response that must be returned as a response to the execution of a method or flow. In other words, a single type of structured response is easy to understand and further exposed, with the possibility of having full control of the messages that are returned. Namely messages, the concept is realized in the form of messages, 6 general types of messages such as:

• Information (Info);
• Warning (Warning);
• Error (Error);
• Nonexistent data (NotFound);
• Restricted access (AccessDenied);
• Exception in the execution process (Exception).

Generally, access is done by calling Result and Success or Failure methods. These two methods are basic and are called initially after all the additional information required has been set.

To be easier to use, but also flexible, extensions have been added to the current solution to set error messages such as:

WithMessage;
WithKeyCode;
WithCodeMessage;
WithError;
WithErrors. In some cases when you may have the necessity to add in the result additional information like the link between the code execution method and data store name: stored procedure, function or table, etc; in code/result is defined object RelatedObject where this information can be stored and returned to the caller.

For more efficient use, in some cases, you may need to execute some custom actions/functions after a successful or failed execution request. In that case, was added extension methods (ActionOnSuccess, ActionOnFailure, ActionOn, ExecuteAction, FunctionOnSuccess, FunctionOnFailure, FunctionOn, ExecuteFunction) which allow you to execute this action/function like insert log when execution has a status equal to failure.

In addition to those mentioned above, within the solution, there is also another series of methods that will surely be helpful. In particular, an implementation is presented that allows the message to be returned in XML form, as in previous versions of web services (SOAP), JSON cannot be returned using XML or in other words, a dynamic response/message cannot be returned.

For more technical information, please consult the available documentation and use terms from the GitHub repository.

Link to the repository:

I-RzR-I / AggregatedGenericResultMessage

This repository can help you to aggregate all results from an API or method in one. So as a result of this, you will have control over all responses given to the caller.

Note This repository is developed in .netstandard2+ with support for SOAP service results mainly used in the .net framework (current support 4.5, 4.6.1 - 4.8)

The goal of this repository is to offer the possibility to manage and agree on the answers received as a result of the execution of a method or a process.

In other words, it offers the possibility to use a single(general) response, structured and easier parsed model for the executed methods As a result, you can have control over the messages and types of messages that will be obtained.

By currently following, 6 general types of messages (Info, Warning, Error, NotFound, AccessDenied, Exception) are implemented that can be returned to the caller As you can see in the MessageType enum, there are 9 types of messages, for all 3 (Info, Warning, Error) types previously…

View on GitHub