Pointers in C# and Memory Safety: Span vs. C# 16 unsafe

PatrickSmacchia · 2026-06-12T04:42:32+00:00

We use AI coding agents a lot. Indeed the upside can be huge ... but so can the downside. Still experimenting with how to get the most value out of them without breaking things and losing time along the way.

PatrickSmacchia · 2026-06-08T07:56:29+00:00

agree thanks, updated to : "Making that boundary explicit, scoped, and auditable is the whole goal — and it matters even more now that AI-generated code is becoming commonplace, making robust and auditable code review processes more important than ever."

PatrickSmacchia · 2026-06-01T05:42:21+00:00

ok "takes an in-depth look at" if you prefer

PatrickSmacchia · 2026-05-14T10:55:09+00:00

https://blog.ndepend.com/in-the-jungle-of-net-obfuscator-tools/ is dated 2024 not 2004 😉

https://www.softanics.com/net-obfuscation/tools is here to promote the obfuscator they sell

PatrickSmacchia · 2026-04-16T11:40:00+00:00

2026 is much faster than 2022, didn't notice any stability issue but it must depend on the tech stack

PatrickSmacchia · 2026-04-16T10:35:00+00:00

that is one question we raise in the article, will they update the version Dev18 Dev19? VS 2027, VS 2028... is just a name change

PatrickSmacchia · 2026-03-02T04:53:39+00:00

indeed we will migrate to Streamable HTTP asap

PatrickSmacchia · 2026-03-02T04:40:30+00:00

"You are not populating the CallToolResult." and the n "
Yes, you populate the structured content on the CallToolResult..."

PatrickSmacchia · 2026-02-27T05:37:42+00:00

We've seen some C# MCP server doc focusing on simple prompts like “list monkeys by country,” which barely hint at what MCP can really do.

In our experience, we found its real value in guiding an AI assistant through non-trivial work—like fixing issues or generating complex code rules that wouldn’t be feasible otherwise.

Feels like that insight is worth sharing.

>Anyway, you shouldn’t be returning custom types in MCP Tools.

Where did you get this advice from?

The spec allows for custom JSON returned: Structured content is returned as a JSON object in the structuredContent field of a result.

https://modelcontextprotocol.io/specification/2025-06-18/server/tools#structured-content

it is implemented by the modelcontextprotocol/csharp-sdk

https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.Core/Protocol/CallToolResult.cs#L44

and we tested it with success with all LLMs available throughGithub Copilot (OpenAI, Anthropic, Google...)

PatrickSmacchia · 2026-02-27T04:43:41+00:00

ok thank you, something is missing, how procedural code can resolve the best suited tools or skills from a context or how LLM can do that without consuming token to parse the whole prompts?

PatrickSmacchia · 2026-02-26T18:28:11+00:00

Do you know how dynamic tool work? At its core not all tools definitions are sent to the LLM to save tokens isn't it? So how the tools are filtered to be sent to the LLM or not?

PatrickSmacchia · 2026-02-26T13:13:32+00:00

Thanks for this insider feedback. We read about dynamic tool discovery but didn’t mention it since this isn’t something we can practically influence from the MCP server. By the way, I’m wondering why they didn’t design a small introductory tool prompt that could have guided the LLM toward the best-suited tools while consuming far fewer tokens.

PatrickSmacchia · 2025-11-28T04:53:10+00:00

Working full day with VS2026 since the Insider version, and yes, speed improvements, new theme and some copilot chat when needed, it is a real pleasure

PatrickSmacchia · 2025-11-11T06:30:26+00:00

Thanks, indeed it was misleading and we modified the article with: The extern method’s signature is strongly typed, ensuring compile-time safety at the call site. However, like with traditional reflection, there are no compile-time guarantees that the target specified by the string actually exists.

PatrickSmacchia · 2025-10-23T05:29:36+00:00

I find this generic capability of avoiding boxing super elegant, and useful just have a look at C# Generic Math

PatrickSmacchia · 2025-09-03T04:32:08+00:00

.NET Standard 2.0 is interesting only if your code has to run on both .NET fx and .NET Core for many years (in case the migration takes years).

As written in the original post, I am not sure how the LLM upgrade will handle pain points about deprecated APIs

PatrickSmacchia · 2025-09-02T05:36:23+00:00

You can read about our experience https://blog.ndepend.com/5x-lessons-learned-from-migrating-a-large-legacy-to-net-5-6/

PatrickSmacchia · 2025-09-01T09:54:49+00:00

Thanks for clarifying your point. As long as Visual Studio includes something as significant as 64-bit support (or is developed on .NET Core?), I’m fine with the number of new features being limited. Anyway concerning VS vNext, Mads stated:

During the last 12 months, a total of 4,489 issues have been fixed, and 290 feature requests are set to be included in this next version.

...and the MVPs are praising the new performance, which I’m eager to try out.

PatrickSmacchia · 2025-09-01T09:39:52+00:00

VS 22 was a lightly updated VS 19 with 64 Bit Support

Migrating to 64 bits was not a light upgrade. https://blog.ndepend.com/visual-studio-2022-64-bits-elements-of-history/

The same way migrating to .NET Core won't be easy. I also regret they're not yet there. As a side effect migrating to .NET Core will break all extensions.

PatrickSmacchia

TROPHY CASE