Forem: Dmitry Dorogoy

C#: Does a Static Constructor Always Run First?

Dmitry Dorogoy — Tue, 03 Mar 2026 17:59:09 +0000

There’s a common misconception — and it often shows up as an interview question:

On the first access to a type, the very first thing that runs is the type’s static constructor.

But if a static field is initialized with an instance of the same type, the order flips: the instance constructor can run before the static constructor. This is not a bug — it’s defined by the CLI/ECMA specification.

Minimal example

class MyLogger
{
    static MyLogger inner = new MyLogger();

    static MyLogger()
    {
        Console.WriteLine("Static");
    }

    private MyLogger()
    {
        Console.WriteLine("Instance");
    }
}

The expectation is often:

Static
Instance

Actual output:

Instance
Static

What the specification actually guarantees

It’s important to separate two concepts:

static field initializers (field initializers),
the body of the static constructor (static MyLogger() { ... }).

During type initialization, code runs in a fixed order:

first — static field initializers (in declaration order),
then — the body of the static constructor.

So if a static field initializer calls new MyLogger(), it triggers the instance constructor before execution reaches Console.WriteLine("Static").

Why this can become a bug

The problem appears when the instance constructor (or anything it calls) assumes the static part of the type is already “up”. But it isn’t — execution is still inside static field initialization.

A real crash example:

class Service
{
    static string ConnectionString;

    static Service Instance = new Service();

    static Service()
    {
        ConnectionString = LoadFromConfig();
    }

    private Service()
    {
        // ConnectionString is still null
        Console.WriteLine(ConnectionString.Length);
    }
}

Here, Instance = new Service() runs before ConnectionString is assigned, so accessing Length will throw a NullReferenceException.

How to fix it (and how not to write it)

1) Don’t create instances in static field initializers when there are dependencies

The simplest way to control the order is to move the creation into the static constructor after setting up the required state:

class MyLogger
{
    static MyLogger inner;

    static MyLogger()
    {
        // first: any static setup
        inner = new MyLogger();
        Console.WriteLine("Static");
    }

    private MyLogger()
    {
        Console.WriteLine("Instance");
    }
}

2) Use `Lazy<T>` for lazy and thread-safe initialization

static readonly Lazy<MyLogger> inner = new(() => new MyLogger());

static MyLogger Inner => inner.Value;

This makes the creation moment explicit: the object is created on the first access to Inner, not during type initialization.

3) Minimize side effects in constructors

If a constructor pulls config, logging, service locator, DI, etc., the risk of “early” access to uninitialized statics is higher.

Takeaway

“Static constructors always run first” is too rough — and misleading in this case.

The correct model is:

on first use of a type, type initialization happens;
inside it, static field initializers run first (in declaration order);
and only after that does the body of the static constructor run.

That’s why static Foo x = new Foo() can trigger the instance constructor before any code inside static Foo() executes.

Surprise: You Can "Intercept" the C# lock Statement

Dmitry Dorogoy — Tue, 17 Feb 2026 22:09:04 +0000

You can “hijack” `lock` in C#. Here is how it works, and why you should not do it.

Many developers think lock is some kind of runtime “magic”. It is not. In most cases it is plain syntax sugar: the compiler rewrites it into calls to System.Threading.Monitor.

That rewrite has an ugly edge case. If your project defines its own System.Threading.Monitor, the compiler can bind to your type instead of the BCL one. In other words, you can change what lock means.

This is a party trick. Also a foot-gun. Treat it as a cautionary tale, not a technique.

Note: starting with .NET 9 and C# 13, lock has a special fast path when the expression is a System.Threading.Lock. In that case, it compiles to using (x.EnterScope()) { ... } instead of Monitor.Enter/Exit.

The hijack shown below applies to the classic lock (object) path.

What the compiler generates for `lock`

For the classic lock (obj) { ... } case, the C# compiler generates code equivalent to this:

object _lockObj = obj;
bool _lockWasTaken = false;
try
{
    System.Threading.Monitor.Enter(_lockObj, ref _lockWasTaken);
    // Your code...
}
finally
{
    if (_lockWasTaken) System.Threading.Monitor.Exit(_lockObj);
}

So lock is not “special” at runtime. It is a compiler pattern that expands into known calls.

The hijack trick

If you define a type with the same fully-qualified name as the BCL type, you can make the compiler call your methods.

Minimal example:

LINQPad snippet: https://share.linqpad.net/dmgs488o.linq

using System;

class Program
{
    static readonly object _sync = new();

    static void Main()
    {
        // Looks like a normal lock, but it is hijacked.
        lock (_sync)
        {
            Console.WriteLine("Working inside the lock...");
        }
    }
}

// We "fake" the system namespace and class.
namespace System.Threading
{
    public static class Monitor
    {
        public static void Enter(object obj, ref bool lockTaken)
        {
            Console.WriteLine("Hijacked: Enter() was called");
            lockTaken = true; // Important: otherwise Exit() won't be called.
        }

        public static void Exit(object obj)
        {
            Console.WriteLine("Hijacked: Exit() was called");
        }
    }
}

Run it and you will see the Hijacked: messages. That is your proof that the compiler bound lock to your System.Threading.Monitor.

Why does this work?

Because name resolution happens at compile time.

Your compilation contains a System.Threading.Monitor type, and there is also one in referenced assemblies. The compiler sees both and chooses one. If it picks yours, the rewrite still happens, but it targets your methods.

This is exactly what the compiler warning is trying to tell you.

Do not ignore the warning

This code should produce CS0436. In this scenario it is not “noise”. It is the whole point.

CS0436 means:

there is a conflict between a type in your compilation and an imported type
the compiler will use the type from your compilation

If your custom Enter method does not actually lock, then multiple threads can run inside the supposed critical section at the same time. That breaks invariants and causes the worst kind of bugs: rare races that are hard to reproduce and disappear under the debugger.

It can also happen accidentally:

a helper class is named Monitor and ends up in the wrong namespace
a dependency ships a conflicting type
warnings are suppressed globally and CS0436 is missed

If you ever see CS0436 around System.Threading.Monitor, stop and investigate.

A safer goal: measure lock contention

If your goal is observability, not sabotage, there is a better approach: measure contention without touching lock at all.

.NET exposes runtime events for monitor contention:

ContentionStart_V2 has event id 81
ContentionStop_V1 has event id 91
ContentionStop_V1 includes DurationNs
the keyword is ContentionKeyword (0x4000)

You can listen to these events via EventListener.

LINQPad snippet: https://share.linqpad.net/6iebniko.linq

using System;
using System.Diagnostics.Tracing;
using System.Threading;

sealed class LockMonitor : EventListener
{
    public long TotalWaitTimeNs;
    int _durationIndex = -1;

    protected override void OnEventSourceCreated(EventSource source)
    {
        if (source.Name == "Microsoft-Windows-DotNETRuntime")
        {
            EnableEvents(source, EventLevel.Informational, (EventKeywords)0x4000);
        }
    }

    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        // ContentionStop_V1
        if (eventData.EventId != 91 || eventData.PayloadNames is null)
            return;

        if (_durationIndex < 0)
            _durationIndex = eventData.PayloadNames.IndexOf("DurationNs");

        if (_durationIndex < 0)
            return;

        // DurationNs is documented as a Double. Convert and keep nanoseconds as a long for easy accumulation.
        var durationNs = (long)Convert.ToDouble(eventData.Payload![_durationIndex]!);
        Interlocked.Add(ref TotalWaitTimeNs, durationNs);
    }
}

What you get with this approach

lock remains a real lock.
You collect how much time threads spend waiting.
You can compare “good” and “bad” code paths and see contention clearly.

If you need a deeper report (per lock object, stack traces, timelines), use tools like dotnet-trace, PerfView, or ETW/EventPipe-based profilers. The small EventListener above is a good minimal demo.

Takeaway

lock is compiler sugar that usually expands into System.Threading.Monitor.Enter/Exit.
A type name collision can change what the compiler emits. CS0436 warns you that you are changing meaning.
Hijacking lock is a neat demo, but a terrible idea in real code.
For diagnostics, prefer contention events and proper tooling instead of tricks.

C# dynamic is a trap door: stop the leaks before they spread (Must read for Dapper users)

Dmitry Dorogoy — Wed, 14 Jan 2026 10:56:30 +0000

In C#, dynamic can be handy at boundaries. The problem is that it can silently leak into places where you expect static typing, and your method signatures can still look perfectly safe.

I ran into these leaks in real projects, so I built a small Roslyn analyzer to catch them early. I am the author of DynamicLeakAnalyzer (NuGet: DimonSmart.DynamicLeakAnalyzer), and this post explains the problem it targets and how to fix leaks at the boundary.

What `dynamic` really means

In C#, dynamic is a static type, but it bypasses compile-time type checking for the expression. Member access, overload resolution, operators, and conversions are bound at runtime.

At runtime, values still flow as object. The difference is that the compiler emits runtime binding (DLR call sites). Those call sites have caching, so repeated calls can get faster after the first bind.

How "dynamic contagion" happens

Two patterns make leaks hard to spot during review:

Invisible runtime work: member access and conversions happen at runtime.
Deceptive signatures: a method can return int and still perform dynamic conversions inside.
var can silently become dynamic: when the right side is dynamic, the inferred type becomes dynamic.

Here is a small example that shows both problems. The method looks fully static and returns int, yet dynamic enters through the parameter.

class Program
{
    static int GetX(int i) => i;

    static void Main()
    {
        dynamic prm = 123;

        int a = GetX(prm); // DSM001: implicit dynamic conversion at runtime
        var b = GetX(prm); // DSM002: b becomes dynamic because the invocation is dynamic
    }
}

In real code, prm is often not a local variable. It can be an object passed into the method, and dynamic can hide in a field or property, for example prm.Payload.Id.

The Dapper trap

Dapper makes it easy to introduce dynamic without noticing it. Calling QueryFirst without <T> returns a dynamic row object (usually DapperRow), so property access becomes dynamic.

using Dapper;
using System.Data;

public static class Repo
{
    public static int GetActiveUserId(IDbConnection cn)
    {
        // QueryFirst() without <T> returns a dynamic row (DapperRow).
        var row = cn.QueryFirst("select Id from Users where IsActive = 1");

        // row.Id is dynamic, the conversion to int happens at runtime.
        return row.Id; // DSM001
    }
}

This kind of code often passes reviews because the signature says int. The dynamic binding is hidden in the middle.

Safer alternatives in Dapper

Prefer typed APIs at the boundary:

int id = cn.QuerySingle<int>("select Id from Users where IsActive = 1");

Or map to a small DTO:

public sealed record UserId(int Id);

int id = cn.QuerySingle<UserId>("select Id from Users where IsActive = 1").Id;

If you really must use a dynamic row, kill it immediately:

var row = cn.QueryFirst("select Id from Users where IsActive = 1");
int id = (int)row.Id;

The goal is not "never use dynamic". The goal is "stop the leak at the boundary".

The solution: DynamicLeakAnalyzer

DynamicLeakAnalyzer is a Roslyn analyzer that makes these leaks loud before they spread.

It reports two rules:

DSM001 (Implicit dynamic conversion): a dynamic expression is used where a static type is expected (return, assignment, argument, etc.). The code compiles, but the conversion happens at runtime.
DSM002 (var inferred as dynamic): var captures a dynamic result and becomes dynamic.

Install and enforce

Add the analyzer:

dotnet add package DimonSmart.DynamicLeakAnalyzer

Make warnings hurt using .editorconfig:

root = true

[*.cs]
dotnet_diagnostic.DSM001.severity = error
dotnet_diagnostic.DSM002.severity = error

Where `dynamic` is fine, and where it is not

Good boundary examples:

COM interop
JSON adapters and glue code
database adapters (including dynamic Dapper rows)

Avoid dynamic in:

core domain logic
hot loops
libraries meant for other developers

Next steps

Run the analyzer on a real codebase and see where dynamic leaks already exist.
If you use Dapper, search for QueryFirst( and non-generic Query( calls that return dynamic rows.
If you have false positives or missed cases, open an issue with a minimal repro.

[Boost]

Dmitry Dorogoy — Tue, 03 Jun 2025 17:57:20 +0000

Dmitry Dorogoy

Jun 3 '25

How I Created a Handy MCP Server in C# to Retrieve NuGet Package Information

#csharp #ai #mcp

Comments 3

8 min read

How I Created a Handy MCP Server in C# to Retrieve NuGet Package Information

Dmitry Dorogoy — Tue, 03 Jun 2025 17:53:49 +0000

User: What time is it right now?
LLM: Um... I actually don't know. I have no idea what time it is.
User: Okay, let's give you some tools. (Clock, Compass and a thermometer)
LLM: I think this clock can be useful. Where are the hands pointing?
User: The small hand is at 9. The big hand is at 12. What time is it right now?
LLM: Now I know the time. It is 9:00.

In this little analogy, the Large Language Model (LLM) couldn’t answer a simple question because it lacked external tools. Only after the user provided a clock (with maybe other tools) the LLM could get the current time and respond correctly. This story illustrates a key idea in modern AI assistants: function calling, or letting an AI to use external functions/tools to get accurate information. In other words - "look out of the box"

Function Calling and why we Need the MCP protocol?

The dialogue above is similar to how new AI assistants can use functions. Instead of guessing or making things up, the AI can call a tool (for example, a clock function) to get the real answer. This method is useful for many types of questions, from checking the time to reading files or calling APIs.

However, to make this work in a consistent way across different tools and platforms, we need a standard protocol. This is where MCP comes in. Model Context Protocol (MCP) is an open standard that lets AI models interact with external tools and services through a unified interface. In simple terms, MCP defines how an AI (or its hosting environment) can discover what tools are available and call those tools with certain parameters, getting back results in a fixed format. Many IDEs and AI platforms (like VS Code’s GitHub Copilot agent mode) support MCP to enable AI-driven development helpers.

How MCP Works (A Quick Example)

MCP messages are typically in JSON. Let’s revisit the clock scenario in technical terms. Suppose the user asks, “What time is it?” The AI, using MCP, would make a tool call request to an MCP server that has a clock tool:

{
  "name": "GetCurrentTime",
  "parameters": {}
}

This JSON request means “call the function named **GetCurrentTime* with no parameters.”* An MCP-compatible server that provides a clock tool would recognize this and return a result:

{
  "result": "2025-06-03T14:42:41Z"
}

Here, the result is the current time in a standard format (ISO 8601 UTC). The AI can then use this result to answer the user’s question accurately.

Now, consider a slightly different query: “What time is it in Madrid?” If our clock tool allowed a location or timezone parameter, the interaction could look like this:

{
  "name": "GetTime",
  "parameters": { "timezone": "Madrid" }
}

And the server might respond:

{
  "result": "2025-06-03T16:42:41+02:00"
}

In this hypothetical response, the time is adjusted for Madrid’s timezone (UTC+2). The key point is that MCP enables passing parameters to tools so the AI can get exactly the info it needs. The protocol handles listing available tools, invoking them, and returning results in a consistent JSON structure.

Hallucinations in Code Generation: A Real Problem

So why did I bother creating a custom MCP server for NuGet packages? Because LLMs hallucinate — especially when writing code. If you’ve ever used an AI coding assistant, you may have seen it confidently call functions that don’t exist or use the wrong parameters for a library. This tends to happen with APIs that the model wasn’t trained on or that have changed over time.

For example, with NuGet packages (which are constantly evolving), an AI might:

Suggest outdated methods or interfaces that were removed in newer versions
Invent non-existent API calls that “sound” plausible but aren’t real
Mix up version differences, using an API from a different version than the one you have
Provide incomplete information, missing important parameters or return details

Such hallucinations can lead to code that doesn’t compile or bugs that are hard to trace. It wastes a developer’s time and erodes trust in the AI assistant.

A Solution: An MCP Server for NuGet Package Info

To tackle this, I built DimonSmart.NugetMcpServer – a small MCP server that gives AI assistants accurate, up-to-date information about NuGet package APIs. Instead of relying on the language model’s knowledge (which might be outdated or wrong), the AI can call my MCP server to get the real data straight from the NuGet package. In other words, the AI asks the server about a package’s interfaces, methods or enums, and the server downloads the package (from nuget.org), inspects its assemblies, and returns the actual definitions. This greatly reduces hallucinations by providing precise API details from the source.

What does the NuGet MCP server do? It currently focuses on interfaces and enums (for now. I'm going to extend). Key features include:

Retrieve a specific interface’s definition from a given package (including all its methods, properties, XML docs, etc.).
List all interfaces in a package, so you can discover what it offers.
Retrieve an enum’s definition from the package.
Support specifying a version of the package (or default to the latest) for version-specific info.
Properly handle generic types and format everything as valid C# code.
Communicate via standard input/output (STDIO) using the MCP JSON protocol, which means it plugs into tools like VS Code easily.

In essence, it’s like a specialized “package inspector” tool that the AI can use whenever it needs authoritative info about a NuGet library’s API. No more guessing what methods FooClient has or what properties interface IBarService includes – the MCP server will tell the AI exactly what’s in the package.

How It’s Built (C# with MCP Library)

I built an MCP server in C# and found it very easy, thanks to the ModelContextProtocol.Server library (v0.2.0 preview). I follow the library’s rules to create tools. I write a C# method and add special attributes so it becomes an MCP tool. Then the server automatically finds these tools when it runs.

For example, here’s a minimal tool that I included for testing – it provides the current time (like our earlier clock analogy):

[McpServerToolType]
public static class TimeTool
{
    [McpServerTool, Description("Returns the current server time in ISO 8601 format (YYYY-MM-DDThh:mm:ssZ).")]
    public static string GetCurrentTime()
    {
        return DateTime.UtcNow.ToString("o");
    }
}

This sample does the following:

The [McpServerToolType] attribute marks the class as a container for tool functions.
The [McpServerTool] attribute (on the method) exposes that method as an available tool to the MCP client, and the Description provides a human-readable (LLM-Readable 😀) description of what it does.
The method itself GetCurrentTime() simply returns the server’s current time as a string. (Notice we format it as string in a standard way "o" for ISO8601 UTC time).

When the MCP server runs, it will automatically find this tool and advertise it to clients. An AI could then invoke GetCurrentTime just like in our earlier JSON example.

Now, the NuGet-focused tools in NugetMcpServer are built with the same pattern. They are just a bit more involved internally: they download the NuGet package, load the .dll, and extract the type info. Here are the main tools provided:

ListInterfaces(packageId, version?) – Lists all public interfaces in the specified package (and version). This returns a list of interface names (and some metadata) so you know what’s available.
GetInterfaceDefinition(packageId, interfaceName, version?) – Returns the full C# definition of a given interface from the package. You provide the package name and the interface you’re interested in, and it gives you the code (methods, properties, XML comments, etc.) as one big string result.
GetEnumDefinition(packageId, enumName, version?) – Similarly, returns the complete definition of an enum type from the package.

Each of these is implemented as an MCP tool with the same attribute approach. For instance, GetInterfaceDefinition is a method decorated with [McpServerTool] and it returns a string containing the interface’s code. Under the hood, it uses a helper service to format the interface nicely (with proper C# syntax) and ensure things like generic type parameters are rendered correctly.

The server uses .NET’s Generic Host with an STDIO transport, meaning it runs as a console app that reads JSON requests from stdin and writes JSON responses to stdout. This makes it easy to plug into VS Code or any other MCP client. The discovery of tools is automatic – thanks to the attributes, the ModelContextProtocol library finds all tools and lists them for the client. So as soon as you run the server, a client can ask it “what tools do you have?” and it will respond with something like “GetInterfaceDefinition, ListInterfaces, GetEnumDefinition, GetCurrentTime,” along with their parameter schemas.

Installation and Usage in VS Code

One of my goals was to make this tool easy to set up and try out. I’m happy to say that NugetMcpServer is available on WinGet, so Windows users can install it with a single command. For example, in a PowerShell or terminal, run:

winget install DimonSmart.NugetMcpServer

This will download and install the latest NugetMcpServer release. DimonSmart.NugetMcpServer alias added automatically, so you can launch it from anywhere (no need to add .exe). By default it uses port-less STDIO, so you don’t have to worry about networking – it just sits and waits for JSON on stdin.

Using it in VS Code (Copilot Agent Mode): If you have GitHub Copilot enabled with the new agent/chat mode, you can add this server as an MCP tool provider. The process is simple (and only needs to be done once): open your VS Code settings, search for “MCP”, and add a new MCP server configuration pointing to NugetMcpServer. (VS Code’s official docs have a section on how to add MCP servers if you need guidance.) Once added, your AI assistant in VS Code can invoke the NuGet tools whenever it gets a related query. For example, if you ask in Copilot chat “Show me what interfaces are in the Foo.Bar package”, Copilot can call ListInterfaces from the server and give you a real answer instead of guessing.

It’s worth noting that to my knowledge this project is one of the first precompiled MCP servers readily available. Many existing MCP tool examples were scripts or needed building from source. By publishing on WinGet, I wanted to ensure anyone can quickly grab a ready-to-run server and immediately enhance their AI dev experience.

Future Plans and Feedback

This project is still in progress. I have a lot of ideas to make AI-assisted development even smoother. For instance, I’m considering adding a feature to search for NuGet packages by description or keywords – imagine asking the AI “Is there a NuGet package for generating QR codes?” and the MCP server could suggest relevant packages by querying NuGet’s catalog. This could help with discovery of libraries, not just usage of known ones.

I’d love to hear feedback, suggestions, or wild ideas from readers like you! Feel free to check out the project’s GitHub repo (linked below) – issues and pull requests are welcome.

Links:

GitHub Repository: DimonSmart/NugetMcpServer – Source code, README, and issue tracker.
My pet projects Live Demo: dimonsmart.github.io/Demo – Some of my pet projects in case you are interested.
About Me: LinkedIn – Dmitry Dorogoy – Let’s connect!

Finally, the project is open-source with a very permissive license. This means you can use it, integrate it, or modify it without worrying about restrictions. I hope this MCP server sparks some ideas and helps make your AI coding sessions more productive and less frustrating. Happy coding!

Automatically Test Your Regex Without Writing a Single C# Line of Code

Dmitry Dorogoy — Fri, 07 Jun 2024 20:41:18 +0000

Introduction

If you've ever used regular expressions (regex), you know there's a saying: "Every problem can be solved with regex. But then you have one more problem."

I hope readers can decide for themselves whether to use regular expressions. However, making sure your regex works correctly can be challenging.

In many development teams, there's always someone who asks, "Have you written unit tests for this regex?"

Developers often add comments above their regex with sample strings that should match or not match.

Often, developers will add comments above their regex with sample strings that should match or not match. For example:

// Matches email addresses
// Example: "test@example.com"
var emailRegex = @"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$";

However, there’s a hidden problem here: these comments can be misleading. A comment might claim a regex matches an example, but without actual testing, there's no guarantee.

The Ideal Solution

According to TRIZ (Theory of Inventive Problem Solving), the best solution is one where the system works effortlessly, without additional manual input. In our context, the perfect scenario would be a system that automatically tests your regex patterns without needing you to write explicit unit tests.

Presenting the Solution: DimonSmart.RegexUnitTester.TestAdapter

The DimonSmart.RegexUnitTester.TestAdapter is here to save the day! This tool allows you to automatically check your regex patterns against provided samples using custom attributes. No more manual unit test writing or misleading comments—just straightforward and reliable regex testing.

How It Works

This library leverages three main attributes to streamline regex testing:

ShouldMatchAttribute: This ensures that your regex correctly matches the expected data.
ShouldNotMatchAttribute: This confirms that your regex does not match unwanted data.
InfoMatchAttribute: This handles ambiguous cases, allowing further analysis without affecting the overall test outcome.

Code Samples

Here are some examples of how to use these attributes in your code:

[ShouldMatch("test@example.com")]
[ShouldNotMatch("test@example")]
public const string EmailRegex = @"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$";

[InfoMatch("123-45-6789", "SSN format")]
public const string SSNRegex = @"^\d{3}-\d{2}-\d{4}$";

With these attributes, you can clearly define which strings should and shouldn’t match your regex patterns. The InfoMatchAttribute is particularly useful for documenting ambiguous cases that need further review.

Conclusion

By using DimonSmart.RegexUnitTester.TestAdapter, you can ensure your regex patterns are accurate and reliable without the hassle of writing manual tests. Give it a try and see how it simplifies your development workflow.

I'm the author of this library. If you have any questions or feedback, please don't hesitate to write me a few words about my library. Happy coding!

You can find more details on installation and usage in the library’s GITHUB.

Stop Scattering .Trim(): Auto-trim All String Properties in C#

Dmitry Dorogoy — Mon, 19 Dec 2022 08:06:54 +0000

Introduction

Once upon a time, I was diving into a new codebase and came upon an intriguing issue. StringTrim() calls polluted the entire codebase. I was taken aback. All user input, in my opinion, should be sanitized by calling at least the Trim function over all string properties. I discovered the problem root after digging a bit dipper. Users frequently copy and paste dates from local notebooks, communications, and so on. In addition, after selecting a string, it occasionally selects with surrounding space and newline characters.
As a result, a simple UserName field could be filled all possible ways:

"John Doe "
" John Doe"
" John Doe "
"John Doe"

Finally, separate program components treat this as if it were one or four different users. Simply because certain components clip spaces while others leave UserName alone.
One amusing (actually not) outcome appears to be a success story: a man registered to the internet business twice (with space difference in the userName). However, the login component treats usernames with and without a leading space as one user. The same is true for the payment subsystem. However, the order handling component sees two distinct users. As a result, the user places one order, pays once, and receives it twice. :-)

Solve the problem with one smart enough nuget Package

Soling this and similar situations as easy as pie. You should never trust user input and always remove leading and trailing spaces. Additionally it's a good practice to remove duplicate spaces inside the strings.

Recommended nuget package is: StringTrimmer

Usage is very simple. Just call TrimExtraSpaces() extension method over any user provided class. And this method automatically trim all public string properties.

public void CreateUser (User user)
{
   user.TrimExtraSpaces(); // Just one line
}

P.S. All string properties are found and trimmed using reflection in this nuget package. This method is better than nothing, but it is not the quickest! To increase class properties trimming speed I'm working on Source Generated StringTrimmmer code.
StringTrimmerGenerator

Feel free to conact me and contribute to the project to make user input safer to use.

Fun with C# Regex based Expression calculator

Dmitry Dorogoy — Tue, 30 Mar 2021 03:17:47 +0000

Hello dear readers!

Once I was asked to write an expression calculator. And my first impulse was to write a classical calculator based on two stacks, also known as shunting yard algorithm. In this approach, one stack is used for values and the other for operators. It's a classical solution but I wanted to do something more interesting and inspiring and fun...

Intro

We have a mathematical expression like: 2 + 2 * (2 + (2)) and we need to calculate the result. There are some problems:

Resolving brackets
Resolving operation priorities

Let's do it with regular expressions!

Bracket expander

The regular expression could be easily used for finding some patterns in the string.
The first simple patter is a pattern for expanding brackets:
Like this: \(\d+\)
This pattern detects an open bracket followed by any number of digits and finally followed with a closed bracket.
This simple regular expression is able to catch the expression: (42).
But how could we extract the number and reject the brackets?
Hopefully, the regular expressions have the ability to catch results into the named groups.
Let's update our regex example: \((?<number>\d+)\)
With this regex, we could find numbers with brackets and take only a number.

Addition operation

Let's check more complex operations. Addition.
For adding two numbers we have to write a regular expression to find the number plus number.
(?<numberA>\d+)\+(?<numberB>\d+)
Here we have two named capture groups and a "hardcoded" plus symbol.
This expression allows us to detect expressions like 1+1.

Multiplication

What's the difference between addition and multiplication? Actually only an operation. So, we use almost the same regular expression to detect multiplication. And the same for division and subtraction

Let's create an expression solver

Let's assume we've got an expression 2*2+(2+2)

At this moment we have got a bunch of regular expressions and small operation evaluators.
In a simple way we've got regular expressions for:
*( number ) => number
*numberA + numberB => sum
*numberA - numberB => sub
*numberA * numberB => mul
*numberA / numberB => div

Step by step calculation

2*2+(2+2)

2*2+(2+2)
4+(2+2)
4+(2+2)
4+(4)
4+(4)
4+4
4+4 => 8

How about priorities?

It's a common question while we are talking about expression evaluators.
And now we could use an interesting feature of regular expressions: Negative lookahead.
The main idea is to avoid matching num + num surrounding with high priority operators (* /).
A bit simplified pattern:
(?![*/])(?<numberA>-?\d+\.?\d*)\+(?<numberB>-?\d+\.?\d*)(?![*/])
Easy as pie. (c) Daddy Pig :-)

How to add constants?

The most common constant is Pi., (3.14). In my solution, we could support constants in the same manner as the opening brackets.
(?i)PI The regular expression "?i" is a case insensitive switch.

How to add math function support?

What is the main difference between a constant Pi and, for example, Sinus function?
Theis only one difference - brackets. And we should construct a regular expression to detect text like Sin(number).
One important moment - we already have an open bracket function. And we also have a potentially conflicted Sin() function. And we have a simple way to solve this kind of problem - expression order!
Let's check an example:(Sin(Pi))+1
To evaluate this function correctly we have to apply regexp substitutions in a particular order:

Replace Pi (Sin(Pi))+1 => (Sin(3.14))+1; Match: Pi
Calculate Sin(3.14) (Sin(3.14))+1 => (0.00)+1; Match: Sin(3.14)
Open brackets (0.00)+1 => 0.00+1; Match: (0.00)
Calculate Sum 0.00+1 => 1.00; Match: 0.00+1

Additional possibilities

I show only small examples with calculating only a simple math expression. Let imagine that our expression is a real DSL (Domain Specific Language) where Sin(x) is not a fast, but really time-consuming function. In this case, we could use the regular expressions ability to give us not only the first but all possible matches. For example, for function Sin(0.5)+Sin(0.5) we detect two Sin function at once. As a result, we could use a parallel calculation.

Experiments!

To continue my experiments, I wrote a classical two-stacks-based evaluator. After I created a random expression generator and run both calculators over the randomized expression until both could calculate expression without errors.

I got expected results:

*( 7 * 6 ) * 2 = 84
*4 ( - ( 5 ) ) = -1
*3 * ( 8 ) * 8 = 192
*7 + ( 1 - 8 ) * 9 = -56

But! also a completely incorrect expression like this:
*8 3 + - ( 9 ) = 2

Regular expression based calculator allows us to see the whole evaluation path step by step:
8 3 + - ( 9 ) => 8 3 + -9; Match: ( 9 )
8 3 + -9 => 8*-6; Match: **3 + -9*
8-6 => 2; Match: 8-6

The classical two stacks algorithm interprets this expression as
(3+8)-9 with the same result 2.

Conclusions

It's possible to create a simple calculator-like expression evaluator based on a regular expression. It's fun.
Classical shunting yard algorithm could evaluate erroneous expressions.

Links

Fun with calculators github repository

Shunting-yard algorithm

DSL

P.S. Feel free to comment/contact me if you like this work.

Forem: Dmitry Dorogoy

C#: Does a Static Constructor Always Run First?

Minimal example

What the specification actually guarantees

Why this can become a bug

How to fix it (and how not to write it)

1) Don’t create instances in static field initializers when there are dependencies

2) Use Lazy<T> for lazy and thread-safe initialization

3) Minimize side effects in constructors

Takeaway

Surprise: You Can "Intercept" the C# lock Statement

You can “hijack” lock in C#. Here is how it works, and why you should not do it.

What the compiler generates for lock

The hijack trick

Why does this work?

Do not ignore the warning

A safer goal: measure lock contention

What you get with this approach

Takeaway

C# dynamic is a trap door: stop the leaks before they spread (Must read for Dapper users)

What dynamic really means

How "dynamic contagion" happens

The Dapper trap

Safer alternatives in Dapper

The solution: DynamicLeakAnalyzer

Install and enforce

Where dynamic is fine, and where it is not

Next steps

[Boost]

How I Created a Handy MCP Server in C# to Retrieve NuGet Package Information

How I Created a Handy MCP Server in C# to Retrieve NuGet Package Information

Function Calling and why we Need the MCP protocol?

How MCP Works (A Quick Example)

Hallucinations in Code Generation: A Real Problem

A Solution: An MCP Server for NuGet Package Info

How It’s Built (C# with MCP Library)

Installation and Usage in VS Code

Future Plans and Feedback

Automatically Test Your Regex Without Writing a Single C# Line of Code

Introduction

The Ideal Solution

Presenting the Solution: DimonSmart.RegexUnitTester.TestAdapter

How It Works

Code Samples

Conclusion

Stop Scattering .Trim(): Auto-trim All String Properties in C#

Introduction

Solve the problem with one smart enough nuget Package

Fun with C# Regex based Expression calculator

Intro

Let's do it with regular expressions!

Bracket expander

Addition operation

Multiplication

Let's create an expression solver

Step by step calculation

How about priorities?

How to add constants?

How to add math function support?

Additional possibilities

Experiments!

I got expected results:

Conclusions

Links

2) Use `Lazy<T>` for lazy and thread-safe initialization

You can “hijack” `lock` in C#. Here is how it works, and why you should not do it.

What the compiler generates for `lock`

What `dynamic` really means

Where `dynamic` is fine, and where it is not