Introduction

C# records and record structs are relatively new. Records offer some advantages over regular classes and structs, which I will cover here, but they are essentially another way to declare them. This is another back to basics article.

We essentially use records for:

• Entities, such as the ones we would store in a database
• Value objects/Data Transfer Objects
• Immutable classes

Let's now see how to work with them.

Syntax

Records are declared like this:

public record Point(int X, int Y);

Or like this, with the exact same meaning:

public record Point
{
    public int X { get; init; }
    public int Y { get; init; }
}

And we instantiate a record just like any other class or struct:

Point p1 = new(1, 2);
//or
var p1 = new Point(1, 2);

We can, of course, use positional or named arguments:

var p1 = new Point(Y: 2, X: 1);

It is possible to add new properties (or methods) besides the ones declared on the primary constructor, we don't need to live with just those properties:

public record Point(int X, int Y)
{
    public int? Z { get; init; } //init-only
    public string? Name { get; set; } //get and set
    public double DistanceToOrigin => Math.Sqrt(X * X + Y * Y); //get only
}

Immutable by Default

Properties declared on the primary constructor on a record are init-only, meaning, you cannot change their values:

p1.X = 10; //error: init-only property X

If we, however, declare properties in the old style, we can have getters, setters, or initialisers.

Reference and Value Type Records

A record is actually a class, and a record struct is a struct, meaning, they are either reference or value types. We can, of course, have nullable records too.

Limitations

A record can only inherit from another record, or Object (the default). A record struct cannot inherit from anything. Both can implement any number of interfaces. Only records can inherit from another record.

For a list of common errors when using records, please see this.

Cloning

Cloning is implemented out of the box, and but we can change some properties on the clone, this is using a with expression:

Point p2 = p1 with { Y = 3 }; //all properties are the same except Y
Point p3 = p2 with { }; //shallow clone

Deconstruction to Tuples

It is also possible to deconstruct a record to a tuple too:

var (x, y) = p1;

Hash Code and Equality

Equality (Equals) and hash code (GetHashCode) are properly implemented for all members, and are stable:

var h1 = p1.GetHashCode();
var h2 = p2.GetHashCode(); // != h1
var h3 = p3.GetHashCode(); // == h1

Comparison is always by value, every property of the record is compared: Equals and the == operator look at what's inside the record.

String Representation

The string representation of a record (ToString) includes all properties of it:

var str = p1.ToString(); //"Point { X = 1, Y = 2 }"

This raises an interesting problem: if we have a property that points to the same object, we will get an exception while calling ToString:

record Data(string Name)
{
    public Data? Parent { get; set; }
}

var data = new Data("Foo");
data.Parent = data;

data.ToString(); //exception because we enter an infinite cycle

Conclusion

I find records to be a great addition; they solve the problem of us having to define equality and hashing, and are particularly good for immutable types. I also like how we can easily get a string representation of all of its contents.

Learn T-SQL With Erik: Heap Table Problems with Updates and Deletes

Chapters

• *00:00:00* – Introduction
• *00:01:01* – SQL Server Specific Content
• *00:02:01* – Free Resources
• *00:03:11* – Upcoming SQL Day Poland
• *00:03:30* – Travel Notes
• *00:03:46* – Pass Summit in Seattle
• *00:04:06* – New Image Update
• *00:04:13* – April Fool’s Joke Video
• *00:04:23* – SQL Server Management Studio
• *00:05:04* – Heaps and Clustered Indexes
• *00:05:30* – Clustered Tables
• *00:05:52* – Load Elhepo Procedure
• *00:06:05* – Forwarded Records
• *00:06:28* – Updating Heap
• *00:07:00* – Forwarded Records After Update
• *00:08:30* – Forwarded Records in Table
• *00:09:01* – Rebuilding Table
• *00:10:53* – Deletions and Heaps
• *00:12:02* – Lob Columns and Heaps
• *00:14:18* – Deleting from Heap
• *00:16:51* – Heaps as Specialized Structures

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.

The post Learn T-SQL With Erik: Heap Table Problems with Updates and Deletes appeared first on Darling Data.

“Is ContosoParts.msix installed?” is a common – but misleading – question

The term install is not a formal concept in MSIX.

This may seem paradoxical for a deployment technology, but it makes perfect sense once you understand MSIX deployment’s core architecture.

Deployment Requests

A caller makes a deployment request to the deployment engine via the PackageManager API to perform some activity. This may involve adding a package to the system, removing one, or performing another management operation. Deployment requests include:

• the requested action
• the target package
• API parameters supplied by the caller
• contextual information about the requesting user (e.g., user ID and security context)

The system queues the request in the deployment engine’s memory for processing by the deployment pipeline.

The Deployment Pipeline

The deployment pipeline processes requests through an ordered set of steps. The pipeline may short-circuit or skip some steps, depending on the request and system state. At its core the processing consists of three primary stages:

• Index
• Stage
• Register

Index

Parse the incoming package’s metadata (for example, AppxManifest.xml) and store that information along with system metadata such as the intended installation path.

Stage

Create the package’s target installation location (also known as the package directory, or pkgdir).

Acquire the package payload and extract it into the pkgdir, and apply appropriate ACLs to secure the content.

Register

Associate the staged package with a specific user profile.

This may involve, among other actions:

• creating Start Menu entries
• registering file type associations
• configuring runtime data

Registering the package effectively makes it usable for that user.

Per-Machine vs Per-User

Indexing and Staging are per-machine activities. The system performs these once per machine.

Staged packages are stored and shared across all users on the system, with the pkgdir secured to allow Read and Execute access — but not Write access — to users.

Registering is a per-user activity.

This separation enables MSIX to alter the set of available packages for one user without affecting others. This isolation — and the controlled servicing it enables — is a cornerstone of MSIX’s design and is reflected in many platform behaviors and APIs.

So… Installing?

To make a package available for a user for the first time, a caller might invoke an Add API:

var packageUri = new Uri("C:\\Packages\\ContosoParts.msix");
var options = new AddPackageOptions();
var packageManager = new PackageManager();
var result = await packageManager.AddPackageByUriAsync(packageUri, options);
...

This sends an Add request to the deployment engine, which:

• Indexes the package
• Stages the package into a new pkgdir
• Registers it for the user

At no point did we technically “install” anything.

Even though we just installed the package

The post There is no Install – it’s ‘Stage’ and ‘Register’ appeared first on Inside MSIX.

Back in 2019, Dominick Baier, Duende Cofounder and Security subject-matter expert, wrote a prophetic post called "Two is the Magic Number", a riff on De La Soul's "Three is the Magic Number", arguing that you only needed two OAuth flows to cover every real-world scenario. At the time, it was a bold simplification. OAuth 2.0 had shipped with a sprawl of grant types: Implicit, Resource Owner Password Credentials, Authorization Code without PKCE, Client Credentials, and the ecosystem dutifully built tutorials for all of them. The result was confusion. Developers picked the wrong flow, shipped insecure apps, and blamed OAuth itself for being "too complicated."

Dominick was right, and the standards body agreed. OAuth 2.1 formally removed the footguns, mandated PKCE on every authorization code grant, and left us with a protocol that is dramatically simpler to learn and harder to misuse. If you're building on .NET 10 in 2026, this is the only article you need. Two flows cover almost everything. A third handles the edge case. Let's go.

Read more of this story at Slashdot.

In Kubernetes v1.36, Declarative Validation for Kubernetes native types has reached General Availability (GA).

For users, this means more reliable, predictable, and better-documented APIs. By moving to a declarative model, the project also unlocks the future ability to publish validation rules via OpenAPI and integrate with ecosystem tools like Kubebuilder. For contributors and ecosystem developers, this replaces thousands of lines of handwritten validation code with a unified, maintainable framework.

This post covers why this migration was necessary, how the declarative validation framework works, and what new capabilities come with this GA release.

The Motivation: Escaping the "Handwritten" Technical Debt

For years, the validation of Kubernetes native APIs relied almost entirely on handwritten Go code. If a field needed to be bounded by a minimum value, or if two fields needed to be mutually exclusive, developers had to write explicit Go functions to enforce those constraints.

As the Kubernetes API surface expanded, this approach led to several systemic issues:

1. Technical Debt: The project accumulated roughly 18,000 lines of boilerplate validation code. This code was difficult to maintain, error-prone, and required intense scrutiny during code reviews.
2. Inconsistency: Without a centralized framework, validation rules were sometimes applied inconsistently across different resources.
3. Opaque APIs: Handwritten validation logic was difficult to discover or analyze programmatically. This meant clients and tooling couldn't predictably know validation rules without consulting the source code or encountering errors at runtime.

The solution proposed by SIG API Machinery was Declarative Validation: using Interface Definition Language (IDL) tags (specifically +k8s: marker tags) directly within types.go files to define validation rules.

Enter validation-gen

At the core of the declarative validation feature is a new code generator called validation-gen. Just as Kubernetes uses generators for deep copies, conversions, and defaulting, validation-gen parses +k8s: tags and automatically generates the corresponding Go validation functions.

These generated functions are then registered seamlessly with the API scheme. The generator is designed as an extensible framework, allowing developers to plug in new "Validators" by describing the tags they parse and the Go logic they should produce.

A Comprehensive Suite of +k8s: Tags

The declarative validation framework introduces a comprehensive suite of marker tags that provide rich validation capabilities highly optimized for Go types. For a full list of supported tags, check out the official documentation. Here is a catalog of some of the most common tags you will now see in the Kubernetes codebase:

• Presence: +k8s:optional, +k8s:required
• Basic Constraints: +k8s:minimum=0, +k8s:maximum=100, +k8s:maxLength=16, +k8s:format=k8s-short-name
• Collections: +k8s:listType=map, +k8s:listMapKey=type
• Unions: +k8s:unionMember, +k8s:unionDiscriminator
• Immutability: +k8s:immutable, +k8s:update=[NoSet, NoModify, NoClear]

Example Usage:

type ReplicationControllerSpec struct {
 // +k8s:optional
 // +k8s:minimum=0
 Replicas *int32 `json:"replicas,omitempty"`
}

By placing these tags directly above the field definitions, the constraints are self-documenting and immediately visible to anyone reading the type definitions.

Advanced Capabilities: "Ambient Ratcheting"

One of the most substantial outcomes of this work is that validation ratcheting is now a standard, ambient part of the API. In the past, if we needed to tighten validation, we had to first add handwritten ratcheting code, wait a release, and then tighten the validation to avoid breaking existing objects.

With declarative validation, this safety mechanism is built-in. If a user updates an existing object, the validation framework compares the incoming object with the oldObject. If a specific field's value is semantically equivalent to its prior state (i.e., the user didn't change it), the new validation rule is bypassed. This "ambient ratcheting" means we can loosen or tighten validation immediately and in the least disruptive way possible.

Scaling API Reviews with kube-api-linter

Reaching GA required absolute confidence in the generated code, but our vision extends beyond just validation. Declarative validation is a key part of a comprehensive approach to making API review easier, more consistent, and highly scalable.

By moving validation rules out of opaque Go functions and into structured markers, we are empowering tools like kube-api-linter. This linter can now statically analyze API types and enforce API conventions automatically, significantly reducing the manual burden on SIG API Machinery reviewers and providing immediate feedback to contributors.

What's next?

With the release of Kubernetes v1.36, Declarative Validation graduates to General Availability (GA). As a stable feature, the associated DeclarativeValidation feature gate is now enabled by default. It has become the primary mechanism for adding new validation rules to Kubernetes native types.

Looking forward, the project is committed to adopting declarative validation even more extensively. This includes migrating the remaining legacy handwritten validation code for established APIs and requiring its use for all new APIs and new fields. This ongoing transition will continue to shrink the codebase's complexity while enhancing the consistency and reliability of the entire Kubernetes API surface.

Beyond the core migration, declarative validation also unlocks an exciting future for the broader ecosystem. Because validation rules are now defined as structured markers rather than opaque Go code, they can be parsed and reflected in the OpenAPI schemas published by the Kubernetes API server. This paves the way for tools like kubectl, client libraries, and IDEs to perform rich client-side validation before a request is ever sent to the cluster. The same declarative framework can also be consumed by ecosystem tools like Kubebuilder, enabling a more consistent developer experience for authors of Custom Resource Definitions (CRDs).

Getting involved

The migration to declarative validation is an ongoing effort. While the framework itself is GA, there is still work to be done migrating older APIs to the new declarative format.

If you are interested in contributing to the core of Kubernetes API Machinery, this is a fantastic place to start. Check out the validation-gen documentation, look for issues tagged with sig/api-machinery, and join the conversation in the #sig-api-machinery and #sig-api-machinery-dev-tools channels on Kubernetes Slack (for an invitation, visit https://slack.k8s.io/). You can also attend the SIG API Machinery meetings to get involved directly.

Acknowledgments

A huge thank you to everyone who helped bring this feature to GA:

• Tim Hockin
• Joe Betz
• Aaron Prindle
• Lalit Chauhan
• David Eads
• Darshan Murthy
• Jordan Liggitt
• Patrick Ohly
• Maciej Szulik
• Wojciech Tyczynski
• Joel Speed
• Bryce Palmer

And the many others across the Kubernetes community who contributed along the way.

Welcome to the declarative future of Kubernetes validation!