What is strong naming

Microsoft describes strong naming in their doc Strong naming and .NET libraries – .NET. In short, it changes an assembly name from a simple “MyUtilities, Version=1.0.0.0, Culture=neutral” to a longer “MyUtilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a4e8f1e6cbfd650b“.

The added PublicKeyToken is a hash for a much longer PublicKey, which has a companion private key that is used to sign the assembly. A strong named assembly is typically signed with this private key, but not always. More on that later.

Strong naming is free. While authenticode signing requires purchasing a code signing certificate, strong name signing does not. These two signing methods address different needs and should not be looked at as alternatives, since they may be used together.

Why strong name?

TLDR: Everyone can reference a strong named assembly. But a non-strong named assembly can only be referenced by other non-strong named assemblies.

Microsoft list several reasons for Why strong-name your assemblies? that I suggest you review.

In their official guidance, the .NET team espouses strong naming for avoiding assembly naming conflicts:

Strong naming refers to signing an assembly with a key, producing a strong-named assembly. When an assembly is strong-named, it creates a unique identity based on the name and assembly version number, and it can help prevent assembly conflicts.

This means if two people produce assemblies called Utilities.dll, .NET Framework can load both of them without getting confused. It still puts an onus on the app developer to deploy these two assemblies to different directories so they don’t clash in the file system, and have an .exe.config file that points to each of them, but it’s only possible if they are strong named. You should still name your assemblies uniquely to avoid conflicts when possible.

Strong naming isn’t about security. The .NET team has said as much officially. They further state:

CONSIDER adding the strong naming key to your source control system.
A publicly available key lets developers modify and recompile your library source code with the same key.

And…

When the identity of the publisher of the code is desired, Authenticode and NuGet Package Signing are recommended.

And in their sn tool documentation…

Do not rely on strong names for security. They provide a unique identity only.

So you see, strong naming is not for verifying the authenticity of the publisher. Therefore, disclosing the .snk publicly in an OSS repo is perfectly fine. You lose nothing as an OSS non-strong-named library by adding a strong name (except binary compatibility with previous versions of your library when a user is running on .NET Framework). You didn’t have publisher security before, and you don’t after. But you gain a whole set of .NET Framework customers who already strong name their assemblies and are technically prevented from referencing assemblies that are not strong named.

Many OSS repos (including all of my own) check in the .snk for their own use and to maintain the spirit of OSS, which is that anyone can modify and rebuild an assembly and use it in place of the original. Strong naming and hiding the private key would violate that, but Strong naming and disclosing the private key maintains that.

Strong Name signing verification

.NET Framework usually doesn’t verify the strong name signature at all, and .NET never does. This further confirms that strong naming isn’t about security. .NET Framework only verifies a strong name signature when an assembly is ngen’d, installed in the GAC, or shadow copied (and a few other less common scenarios). None of these happen in the normal process of loading and executing an assembly in an application.

Because these runtimes so rarely (or never) verify the signature, the C# compiler added a switch to do what it calls public signing. With public signing, a public key is used to strong name an assembly, but its signature is all zeros, and the private key is never used. This is an invalid signature, but it works fine on .NET. It also works on .NET Framework so long as the assembly is not GAC’d, ngen’d, or shadow copied, etc. If you release assemblies for others to use, please use properly signed as

For completeness, I’ll mention that another concept called delay signing also exists. There are precious few reasons to do this and it significantly complicates a build. I do not advocate anyone to start doing this.

Caveats

A strong named assembly has a couple limitations:

1. It can only reference other strong named assemblies.
2. It can only expose its internals via InternalsVisibleTo to other strong named assemblies.

These constraints put something of a semi-viral requirement on a family of assemblies, whether they are strong named or not. If a team or product tends to strong name their assemblies, their dependencies need to as well. Similarly, if that team does not strong name their assemblies, no one downstream of them can either.

If it’s viral either way, how do you decide which side to be on? Well, as an individual assembly author, you gain more audience by being strong named. You only win users by strong naming, because everyone can reference a strong named assembly, while only a subset of users can reference your library if you don’t strong name.

Counter-arguments and rebuttals

Claim: “Only enterprises strong name their assemblies.”

Fact check: false. For reasons given above, many developers including OSS developers strong name their assemblies to increase their audience.

Claim: “If someone wants to use my library, they can strong name it themselves, or pay me to strong name a private copy for them.”

There are a couple tools out there that automate adding a strong name to an existing assembly. There are significant downsides to this, however. Applying a strong name to an existing assembly changes its identity for the CLR, so any other assembly that referenced the original will refuse to run against the strong named version.

Claim: “I can ship a strong named and non-strong named assembly in separate nuget packages.”

This is about as disastrous as can be. Consider you ship package Z and Z.Signed. Along comes nuget package M which is strong named so it depends on Z.Signed. Package N is not strong named and decides to depend on Z. Now app or package A comes along and consumes M and N. Now we have a problem, because Z.dll is in the dependency graph twice — once with a strong name and once without. The compiler of A.exe or A.dll gets all the types in Z.dll twice and you get compile errors. You also have deployment issues because msbuild tries to copy Z.dll twice. And .NET won’t be able to load both anyways.

Please do not ship both strong named and non-strong named assemblies. Just add a strong name to your existing assembly and bump the major version number (because it’s a binary breaking change for .NET Framework users).

Strong naming and .NET

While .NET Framework considers a strong name to be a crucial part of an assembly’s name, .NET (as in Core CLR) does not. By default, .NET disregards a strong name completely. This has a couple ramifications:

1. Strong naming is not a means to load multiple assemblies with the same name but from different publishers into the same process for a .NET app.
2. As .NET Framework gives way to .NET, the call to strong name assemblies becomes less relevant. However, there are still many folks who run on or at least support .NET Framework, which is still fully supported by Windows. So this is a long way off.

How to start strong naming your assembly

Giving your assembly a strong name is easy and free. First, generate a strong name signing key with the sn tool:

sn -k strongname.snk

The sn tool comes with the .NET Framework SDK, which you can freely install if you have a Windows machine handy. Or on a non-Windows machine you can install mono to get sn as well. The .snk file that you generate will work on any OS and to build any assembly with the .NET SDK via the dotnet build.

Go ahead and check in the .snk file you generate into your source control system. Yes, it contains a private key, but as stated above, strong naming isn’t about security so sharing this private key publicly is just fine. I do this for all my OSS repos.

Now add two properties to your project.

<PropertyGroup>
  <SignAssembly>true</SignAssembly>
  <AssemblyOriginatorKeyFile>strongname.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>

Alternatively, you can define these properties in your Directory.Build.props file at the root of your repo to strong name sign all your projects at once. Move the strongname.snk file to the root of your repo and then add these properties:

<PropertyGroup>
  <SignAssembly>true</SignAssembly>
  <AssemblyOriginatorKeyFile>$(MSBuildThisFileDirectory)strongname.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>

At this point, you may be done. Try building. The build may fail for a couple reasons:

1. Your projects reference assemblies that are not yet strong named. If these are 3rd party dependencies, file bugs against them asking them politely to strong name their assemblies. Link to this article to help alleviate their concerns and instruct them on how to proceed. Your progress in strong naming your assembly is blocked until your dependencies strong name or you drop those dependencies.
2. You have InternalsVisibleTo attributes in your project that need to be updated to include the PublicKey of the referencing assemblies (which now also must be strong named). Since you presumably have control over the assemblies that you are offering internals visibility to, you should be able to strong name these as well and then update your attribute. Getting the value to use in PublicKey can be tough at the command line. But in a C#-aware IDE like Visual Studio, a completion list is offered that makes updating these attributes really easy. And if you’re using Nerdbank.GitVersioning you can just reference ThisAssembly.PublicKey to get the value:
   [InternalsVisibleTo("My.Tests, PublicKey=" + ThisAssembly.PublicKey)]
   Note that this is the public key itself rather than the much shorter public key token seen in an assembly’s strong name.

Congratulations on strong naming your assembly. And thank you for making your assemblies available to a broader audience.

We call it open source because its parameter weights are publicly available, making it self-hostable. But what are these weights? Simply put, they’re a bunch of numbers. We have no idea what they mean except through experimentation—sending in prompts and observing the outputs. This is less transparent than an executable binary because, at least with a binary, you can inspect the text strings inside. Instead of calling an LLM with published weights “open source,” we should think of it as a freely redistributable binary that is both encrypted and executable. Would you run that on your machine? In fact, Ben Thompson has also highlighted this issue and proposed the term “open weights” for LLMs like DeepSeek.

So, what would truly constitute “open source” for an LLM? Like traditional open source, it would need to be reproducible. A binary is considered open source if you can recompile it from human-readable source code and produce the same binary, byte for byte. Otherwise, you can’t be sure what went into that binary. Recompiling from source is relatively inexpensive, but recreating an LLM’s weights from its source—including all the inputs, training instructions, and more—would be prohibitively expensive in terms of computational and hardware costs. Most people wouldn’t (and couldn’t) do this just to satisfy their curiosity about verification.

If the organizations behind an LLM like DeepSeek share their weights under a freely redistributable license but don’t provide the exact instructions and inputs needed to recreate those weights (or if no trusted organization has verified the process), we must treat it like an encrypted executable. But why? What harm could an LLM possibly cause?

The potential harms are significant. There’s the human safety factor, censorship concerns, and more—issues that organizations like OpenAI regularly test for before releasing their models. But when we consider LLMs published by countries or organizations we don’t trust, there’s an even more nefarious possibility: code injection.

Yes, one of the most popular and growing uses of LLMs is to write source code for developers. Developers might prompt an LLM to write a program to accomplish a specific task, and the LLM can often do a surprisingly good job. But what if that LLM were trained to write programs with a hidden second purpose? What if it generated code with backdoors that only a meticulous audit could detect? After all, security vulnerabilities in software are already hard to find, and those are usually accidental. What if security holes were deliberately introduced, allowing the LLM’s creator to exploit programs running on computers, devices, and web apps?

There’s no way to vet a black-box LLM—even a freely redistributed one like DeepSeek—against this risk. You could reduce the risk by asking it to generate many programs and then carefully reviewing the code for signs of malicious training, but that’s like searching a 1-billion-pixel photo for a specific shade of blue, one pixel at a time. And it’s possible that only certain prompts, like “create a login page for a government website,” would trigger the generation of malicious backdoor code, making it unlikely to be detected during testing.

Another possibility is indirect poisoning of an LLM. Imagine commissioning a group of people to create hundreds of simple applications and publish their source code on GitHub. These apps could contain hidden backdoors, but their code comments and documentation would tout their high quality and functionality. Eventually, an LLM developer might use this open-source code to train their model, inadvertently incorporating the faulty, backdoored code. In this scenario, even “trusted” LLMs could end up producing exploitable code.

Now, I’m a huge fan of DeepSeek R1 (the reasoning version). I’m absolutely amazed at what it can do, and I appreciate that it’s freely available online. But it makes me wonder: who will we trust to create the LLMs that write our code, make health decisions, and handle other critical tasks that we eventually rely on for our safety and security? Will we ever develop a better way to directly vet the trustworthiness of LLMs, rather than relying solely on the reputation of their creators?

What do you think?

The MessagePack format, by the way, is a compact binary format that is available for every platform and virtually every language. It is similar to JSON but has more features.

For my part, I’m shifting my attention to my new Nerdbank.MessagePack library. It’s just about as fast as MessagePack-CSharp, much simpler to use, and so much simpler to maintain that I could achieve rough feature parity with MessagePack-CSharp in just a couple weeks. It also has unique features including async serialization support, .NET trimming and NativeAOT support. It is designed to allow faster innovation and greater flexibility in use cases. It has a whole bunch of C# analyzers to help you do the right thing, great docs, and includes migration helps to automate most of the work should you choose to switch your application to use it.

Learn more about perf comparisons and why the need for a new library over at the github repo.

I have to give a shout out to Eirik Tsarpalis for his most excellent and exciting PolyType library, which is what inspired this new library and made it so easy to build while supporting modern NativeAOT.

So please, check out Nerdbank.MessagePack for your serialization needs.

I was a fast qwerty typist. 100 WPM was typical for me. But some were faster and I was interested both in getting faster and in improving the ergonomics to avoid things like carpal tunnel. Dvorak is sold as technically superior. It was scientifically engineered for speed and ergonomics, whereas qwerty was allegedly arranged deliberately to slow typists down to avoid old mechanical type writers from jamming up. Sure, it would mean I need to learn a new keyboard layout. But I’m a fast learner. How hard could it be?

Add to that the attraction of the Kinesis Advantage2 keyboard, with both unique and compelling ergonomics and sold with optional key caps for Dvorak. And a friend and coworker who swore by Dvorak and this keyboard. I decided to go all in.

Switching to and living with Dvorak

Rather than taking a month or two to transition as my friend suggested, it took many months before I could consider myself fluent in Dvorak. Knowing qwerty made it difficult to learn Dvorak until I immersed myself in it — not allowing myself to ever use Qwerty. I used EdClub to learn Dvorak as they have lessons specifically for that layout, which are easy and fun.

Dvorak is great. It is more ergonomic. The claim that the most commonly typed characters are on the home row makes a huge difference. Sometimes it feels like the whole alphabet is on the home row because I can type so much without moving my fingers far at all. And the Advantage2 keyboard magnifies this amazing experience.

My Dvorak typing speed is 117 WPM. At best, marginally faster than my speed with Qwerty.

Using Dvorak has several very real, practical problems:

When you learn a second human language, you may be able to speak it and your original language fluently. But with typing, at least in my experience your fingers only have muscle memory enough for one keyboard layout. My qwerty typing is almost non-existent at this point, which leads into the first real problem…

Every single keyboard around me is qwerty except one of mine. When my family want to use my computer, I have to plug in an alternate keyboard so they can actually type. Every computer in my house has dual keyboard layouts configured in the OS so that I can switch to Dvorak when using them and my family can use Qwerty. All my family members then have to learn how to switch layouts in the OS in case I used it last. When I’m using a friend’s computer, I have to type with their qwerty layout and it’s painfully slow, and to save embarrassment I have to explain that I am a good typist — on Dvorak.

Keyboard commands in games and keyboard shortcuts in apps are all based on character placement on a qwerty keyboard. Cut/Copy/Paste shortcuts are all neatly in a row as Ctrl+C, X and V — on qwerty. They can also be (and this is super useful) all executed with just the left hand, while my right hand is operating the mouse, busy selecting something to copy and pointing where to paste. But on Dvorak, two of these characters are on the right side of the keyboard, leaving only X (Cut) operable with the left hand. There are many other keystrokes that I had learned to do with one hand, or perhaps with two hands even with 3-4 keys at once, because of their qwerty placement, that on Dvorak are much less convenient.

I’m not a big gamer, but on the occasional time I play, games that use the keyboard (A-S-D-W anyone?), I have to fumble through game settings and redefine all the buttons so they are convenient on Dvorak. And unlike the OS which has convenient ways to swap between Dvorak and Qwerty, games I’ve played tend to only have one keyboard mapping, making it a major pain to switch between my own layout and one that works for literally everyone else I share a computer with.

Now, all my computers that I directly interface with are laptops. So this Advantage2 keyboard I use is only useful with my machine when my laptop is docked on my primary work desk. That means my laptop has to itself have the software keyboard layout switch ready to go too, since the Advantage2 masquerades as Qwerty to the OS, but the built-in keyboard doesn’t. If that’s confusing to you, that’s because it is. But compound that with the fact that most of my work isn’t on my laptop OS at all… I usually remote into another machine to get work done. So now all the remote machines I connect to also need 2 keyboard layouts configured. And the keyboard shortcut to switch between layouts (Alt-Ctrl or Ctrl+Shift) will affect both the remote machine and my local device. So if I have the local device set up, then remote into another machine and I have to switch the layout, guess what… now my local device has the wrong layout waiting for me when I close the remote window. Add to that the fact that these key combinations are frequently hit accidentally, switching my layout and making me type gibberish for a word or two before I realize my mistake and correct it.

Switching back to Qwerty

The transition to Dvorak was absolutely not worth it. I figured that out about a year in. Now I’m several years into it, and for the last year or so I’ve been asking myself whether switching back to qwerty would be worth it. After all, I’d have to re-teach myself to type again. And how will this Advantage2 keyboard feel with qwerty key caps put back on it anyway?

I’ve recently decided to take the plunge and switch back to qwerty. I started today by using a qwerty hardware keyboard with qwerty configured in the OS. Oh, it was painfully slow and error prone. I haven’t yet replaced the key caps on my Advantage2 keyboard, so I’m typing Dvorak now for this post. I hesitate… is this the month I want to take a huge productivity hit to switch back?

The grass is greener on the other side. I know, because I’ve been there. But just how big is this hill that I’ll have to climb to get there? Hopefully not as high as it was the last time I passed over it.

It turned out I didn’t need the NVMe enclosure because my motherboard has room for two such devices. I added the new 4TB device to the motherboard and booted Windows from the 1TB device.

Using Macrium Reflect Home (a product you purchase or use within a 30 day trial period), I cloned the 1TB drive to the 4TB drive. I did not partition the 4TB drive first, and instead, I cloned all partitions from the 1TB drive to the 4TB. This seemed prudent because Windows presumably created those other 2-3 partitions for UEFI boot reasons. The one change I made in preparing the clone operation was to slide the last (small) partition all the way to the end of the 4TB drive to give room for the main partition to expand to fill the space. This would give me the full extra TBs of storage on the C: drive in Windows rather than force me to create a D: and move data to it.

The clone operation did not automatically enable bitlocker on the target device either, so after the clone operation completed I applied bitlocker immediately. Even before a reboot. This was probably premature, as you’ll soon see.

Cloning itself was pretty fast, which was great. The clone operation was supposed to leave the target drive in a bootable state. It did not. The rest of this post contains the steps I took to get back into a working condition.

When I used the BIOS to change boot device selection to the 4 TB device, things didn’t go well. I bounced between getting no bootable device found errors and bitlocker recovery screens. It didn’t matter how many times I entered the recovery key, it would ask me for it again.

So I used Macrium Reflect Home to create “Rescue Media” in the form of a USB drive. This booted, found my two NVMe drives, each with Windows on them. It was pretty easy to use this tool, and it was supposed to let me pick which Windows installations to offer at bootup, and select which drive I would then set in the BIOS as the boot media. In theory, that’s great. But I had to run this step 3-4 times before it really worked. And ultimately, it left me with a 4TB Windows boot sequence that demanded I enter the bitlocker recovery key on every reboot.

Suspend/resume bitlocker in Windows didn’t fix it. There was no “Auto-unlock” option offered, presumably because this was the OS drive but I don’t know. In desperation, I removed bitlocker entirely, and rebooted. As expected, no recovery screen challenged the boot up process. So then I tried to re-enable Bitlocker, but I get this weird “The system cannot find the file specified” error each time I tried to start the encryption process.

Luckily Lee Qicheng offered a simple and effective solution to the Bitlocker error message on a Microsoft forum I found through a Bing search. That worked brilliantly, and Bitlocker recommended I reboot to test before encrypting the drive, which I accepted. Rebooting did not challenge me for a recovery key. Yay!

So the last thing I need to do is remove my 1TB NVMe and find some new use for it. I’ll probably use it as a huge USB drive by sliding it into the NVMe enclosure that I already have.

In summary, Macrium Reflect had some tools I needed for the disk cloning. And their software was easy to work with. It’s just a shame that it left me in a broken state that took a few hours to work through before I was in a ready-to-use state again. If I were to do this again, I might try a competing product to see if it does the job right the first time.

I wrote a tool that automates cleaning up your local branches that have already merged, reducing the tedium to just these commands:

git fetch upstream
repo git trim upstream/main

repo is a dotnet CLI command you can install as a global tool:

dotnet tool update -g Nerdbank.DotNetRepoTools

You can repeat the above command periodically to make sure you have the latest version. Note that the update sub-command used above works for original installation as well as updates.

This repo tool has many other commands that are useful around git, nuget, and other common scenarios. Learn more about it here in its README:

AArnott/DotNetRepoTools: A CLI tool with commands to help maintain .NET codebases (github.com)

Why would you exfiltrate secrets from Azure Pipelines

Exporting secrets is typically a bad thing. Secrets are meant to be hard to share, and a secret that is exposed to Azure Pipelines but not to other users should typically remain a secret known just to your build agent and pipeline. But on very rare occasions I’ve found myself needing to recover or export a secret that Azure Pipelines was entitled to but I wasn’t, although I owned the pipeline.

In such cases, it’s still important to respect the secret and keep it from prying eyes.

Encrypting the secret for export

Merely logging the secret may fail due to the automatic redaction. While you may be able to defeat this through some trivial encoding tricks on the secret (e.g. base64, hex), doing so also exposes your secrets to the bad guys. The high-level strategy will be to simply log the secret in some encrypted form so that though anyone will be able to observe the encrypted secret, only you will be able to decrypt it.

In my technique I’m using .NET encryption APIs that are only implemented when running on Windows, so if your secret is only available on linux/mac agents, you’ll have to switch to a Windows agent first if you’re going to use the particular code in this blog post.

In studying up for how to do this, I started out with the following blog post, which seemed applicable because I had access to the secret in my pipeline from a powershell script:

But this post kept symmetric and asymmetric encryption as separate functions that couldn’t interoperate. Symmetric encryption wasn’t appropriate because that means the pipeline would also have the key to decrypt the secret in order to encrypt it. And if the pipeline YAML contained that key, then anyone else would be able to decrypt the secret too. Asymmetric encryption only worked in a trivial test case because it has a limitation on the length of the secret being encrypted. So I had to combine the two.

I rewrote just about all of the powershell scripts from the above blog post then in order to provide simple cmdlets I could use within the pipeline and from my own machine. The scripts first create a new symmetric key and encrypt the secret with that. The symmetric key is then asymmetrically encrypted, and the encrypted key, the symmetric IV and ciphertext is then logged. On my end, that process is then reversed using my private key in order to recover the original secret.

With the code included at the bottom of the post, I could now take the following steps:

Create a new RSA key and print the public key for checking into the pipeline:

$key = New-AsymmetricKey
[Convert]::tobase64string($key.PublicKey)     

It is critical that I keep that particular Powershell window open until the conclusion of this, because the $key is needed later to decrypt the logged, encrypted secret. I could also have serialized and deserialized the key later if needed, but keeping the window open is easier.

Then I added the EncryptionTools.ps1 file to the repo, imported it into a powershell context, and encrypted the secret. In my case the secret was a text access token. The last step prints out a JSON blob containing the ciphertext and other details I need:

. "$(System.DefaultWorkingDirectory)/azure-pipelines/EncryptionTools.ps1"
$PublicKey = 'UlNBMQAMAAADAAAA...UA7VWDL2d'
$PublicKey = [Convert]::FromBase64String($PublicKey)
$secret = [Text.Encoding]::UTF8.GetBytes($accessToken)
Encrypt-Data -Data $secret -PublicKey $PublicKey | ConvertTo-Json

After running the pipeline, I got JSON like this in my Azure Pipeline console log:

{
  "EncryptedKey": "TjE9Av7Z...mfCz",
  "IV": "2BtjqsymGwFoEuAIyAL3lQ==",
  "Ciphertext": "uPm3lx...Bge5OCHiI="
}

I then imported the logged JSON and decrypted the secret like this:

$packet = '{ "EncryptedKey": ... }' | ConvertFrom-Json
$secret = Decrypt-Data -EncryptedPacket $packet -PrivateKey $key.PrivateKey
$accessToken = [Text.Encoding]::UTF8.GetString($secret)

I now have the access token from Azure Pipelines, in such a way that it would be impossible for anyone except me to decrypt it. In my case, I could now run my local REST API tests far more quickly than I could do by running the pipeline over and over again.

The code that makes the above Powershell script work is below:

This post will focus on hosting your own agents on Azure Pipelines. Private agents aren’t always free either (interestingly). In fact, you pay $15 per parallel job for the privilege of providing your own hardware while Azure Pipelines coordinates the work. The first private agent is free. Visual Studio Enterprise subscribers get 16 private parallel jobs allocated at no extra cost.

There’s another potential benefit to hosting your own agents: much faster builds. Some of my 25 minute jobs dropped to just 3-5 minutes by moving to private hardware. This came from a combination of my hardware being faster than the slow machines they offer for free, and because my machines aren’t totally recycled after each job, so prerequisites and caches are left on the machine between jobs, allowing subsequent jobs to do less work.

In the migration to a private agent pool that I just finished, I had agents for all 3 OSs. Your project may not need agents for all 3 OSs though, so feel free to skip to the sections below that are relevant to you. The short pitch though is that although it took a lot of work to figure out how to do it, it isn’t a lot of work to do it. So I hope to save you a bunch of time by giving you the recipes.

Azure Pipelines offers the agent software to install on each of the OSs, and getting the software to run and register itself with your Azure DevOps account as an available agent is the easy part. The tricky part is getting a stable system, where the agents have all the software your pipelines will need, because while Microsoft publishes the list of all software installed on the build agents, you have to install it yourself. Or at least the subset of the software that your pipelines require.

For all private agents, keep in mind the security implications of running builds of arbitrary code. If you trust the code, and you don’t build pull requests from strangers, you may consider waiving the security concerns. This blog post is about my experience setting up agents for a private, trusted code base. I made some decisions that would be very unwise if I were building OSS software that accepted outside pull requests.

While I am pleased to share my hard-learned methods here, I freely admit there is a lot more to learn for better setup on each OS. If you know how to improve on these methods, please comment and I’ll be delighted to update these instructions.

Windows agents

Microsoft published a great doc on running your Windows build agent inside a Windows docker container. In my case however, I wanted my Windows machine to be able to create linux containers, and the docker software for Windows can only be switched between Windows and linux container modes such that you cannot have a mixture of containers of both OSs.

So I opted to use Hyper-V to create a Windows VM on which I would run the agent directly. I used the Quick Start option to create a VM based on the “Development VM” image.

Additional software I installed:

• Rust
• PowerShell on Windows – PowerShell | Microsoft Learn
• Visual Studio, with several workloads including C++ so that rust can find the native toolchain it requires.
• Azure Pipelines build agent

I then had to run the agent interactively so that it ran under the same user account that I installed rust on, so that builds could find the rust toolchain.

I would have preferred to run the agent as a service so that on reboot it automatically starts, but I didn’t know how to get rust to work in that environment.

Linux agents

Microsoft published a great doc on running your Linux build agent inside a Linux docker container. In my setup, I started with these steps and then evolved to enable docker-in-docker so that my pipelines could run cross build (a cargo build step that uses docker containers).

I used Hyper-V’s Quick Create to create an Ubuntu 22 VM on my Windows machine.

I am using a linux container for the build agent, so I didn’t need to install any build tools onto the VM itself. Here is the command I used to install a few useful tools though:

sudo apt install -y openssh-server docker.io net-tools screen

I then configured SSH so I could remote in as needed:

sudo systemctl enable ssh
sudo ufw allow ssh

I also reconfigured SSH to deny password-based authentication, as I prefer the security and convenience of key-based auth: How To Configure SSH Key-Based Authentication on a Linux Server | DigitalOcean

Because Hyper-V Quick Create gave me a tiny (12GB) volume for my VM’s disk, I had to enlarge it. I shut the VM down and deleted the snapshot that Hyper-V automatically created. That allowed me to Edit the .vhdx to be much larger. I then booted the VM and had to run commands documented here to get the file system to expand to fill the enlarged virtual hard drive.

Next comes the magic: docker-in-docker. I intend to run the build agent itself in a docker container. Some build jobs require creating docker containers, which doesn’t work by default. A lot of documentation out there talks about the security risks of enabling docker-in-docker that come from mounting docker.sock from the host into a container, with good reason. But I found another way, courtesy of this excellent article that outlines the options: How To Run Docker In Docker Container [3 Methods Explained] (devopscube.com).

By installing sysbox and slightly adjusting my dockerfile and how I launch it, my build agent container can now spawn child containers, such that the build agent container does not need access to manipulate top-level containers or the rest of the linux VM. After installing sysbox, I specifically:

1. Installed docker.io onto my build agent docker image via apt.
2. Added --runtime=sysbox-runc to docker run the command line I use to start the build agent container.
3. Modified the entrypoint in the dockerfile to run dockerd > /var/log/dockerd.log 2>&1 & before launching the AzP start.sh script.

You can see the whole recipe with dockerfile and scripts here:

I use the build-and-run.sh script on the linux VM to start one or more linux agent containers.

macOS agents

I bought a relatively new Mac Mini for about $500 on eBay. After a low-level reinstall of the OS to verify there would be no remnants of its prior user, I installed the following software:

• PowerShell – PowerShell | Microsoft Learn
• Rosetta (so that x64 build tools can run) by running this command:
  /usr/sbin/softwareupdate --install-rosetta --agree-to-license

I then created a buildagent user account, and within it, I installed:

• rust: curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh
• The Azure Pipelines agent

Finally, I launched the Azure Pipelines build agent software by invoking ~/myagent/run.sh within the buildagent user account.

I wish I could have configured this to automatically restart the agent every time the machine restarted, but I don’t know how to do that. As a result, I have to be careful to not sign buildagent out, and remember to repeat the run.sh command within that account after each restart.

Reconfiguring your pipelines to use your private agents

With your private agents running in your new private pool in your Azure DevOps account, it’s time to configure your pipelines to use them instead of the public Hosted pool.

pool:
    name: CustomAgents
    demands:
    - Agent.OS -equals Linux
    - HasDockerAccess

With that, your pipeline (or an individual job on your pipeline) will run on your CustomAgents pool, and in particular on your Linux agent. You can also use Windows_NT or Darwin for your Windows or macOS agents, respectively. The HasDockerAccess demand is unique to linux, and ensures that you get a linux agent from your pool that allows docker-in-docker as described earlier. This may not be important to you, and you might leave it out.

Finally, given that you may have some free public Hosted pool time, you could perhaps save money and hardware by having your pipelines dip into multiple agent pools by having some jobs in your pipeline choose the Hosted pool while other jobs use your private agents. Unfortunately, there is no way for a given job to indicate that they’ll run on either of two queues, whichever is available first.

I found that there were slight disparities between my private agents and the Hosted ones (probably due to differences in installed software) that required a couple slight changes to my pipelines to accommodate, or added software to install on the agent.

Summary

I’m very happy with the money I’m saving by hosting my own build agents instead of paying for Hosted ones for my private git repos. I’m super happy that my pipelines execute much faster as well. My private agents run on some pretty nice hardware in my home. If you didn’t have the hardware before, I expect buying it is a great investment that will pay for itself within a few months in saved monthly Hosted compute costs, but you should do your own math to see what is right for you.

Also keep in mind that while I have Windows and Linux agents running in distinct VMs on the same hardware, this leads to each build job running slower as they compete for the same hardware resources. You may want to scale out with more hardware and spread your build agents out.

And just as a reminder, I’m not an expert in this area. I’m thrilled to have set this up and want to share with others so they can do the same. But no warranties are expressed or implied here. And if you know of improvements that can be made, please comment and I’ll be happy to update this doc to incorporate your suggestions.

if (somearg is null) throw new ArgumentNullException(nameof(someof));

This is a great use for nameof because if somearg is renamed, the string value passed to the exception’s constructor will change too, which is definitely what you want.

There are times however when a string may match the name of an identifier, but nameof should not be used. Surprised? Read on.

Some constants that you may define have string values that must not change. Consider this example of an HTTP header:

private const string Authorization = nameof(Authorization); // BAD

Here’s the problem: a rename refactoring command in your IDE (that might be activated wherever the Authorization constant is referenced) won’t just change the member name; it will change its value as well. And in the case of a protocol magic string, that will break your compliance with the protocol.

For example, suppose you had a reference to this constant:

request.AddHeader(Authorization, "Bearer abc");

And further suppose you decided that AuthorizationHeader would be a nicer name for this constant, so you triggered a rename refactoring on Authorization right there on the reference to obtain this:

request.AddHeader(AuthorizationHeader, "Bearer abc");

Unbeknownst to you or the C# compiler, you’ve now changed the value of the header itself:

private const string AuthorizationHeader = nameof(AuthorizationHeader); // OOPS

That will break your HTTP code, of course.

The following syntax is therefore more resilient:

private const string Authorization = "Authorization"; // GOOD, resilient code

A rename on the constant will only change the member name and leave the string literal as it should be.

What are persisted strings?

Let’s review which strings that are better left as string literals and avoid nameof(x).

If the string value is persisted in any way (written to disk, the network, or saved in another assembly) aside from the constant declaration itself, it should remain as a string literal because changes to these values would likely break functionality if they were to be changed in the program while the persisted form or other programs retained the original value. Here are a few examples of when to avoid nameof:

• Protocols: As in the example above, communication protocols are between 2 or more programs, typically running on different processes or machines. They each have a copy of the constant that they are going to read or write. If you change your copy, you haven’t changed theirs, and communication will fail.
• Database schemas: Databases persist column and table names and expect exact matches for subsequent access. A renamed C# identifier doesn’t rename the database entity.
• Embeddable strings: The C# compiler will sometimes embed a copy of a constant string in a referencing assembly. Attribute values are a classic case for this. If your assembly declares
  public const string MyConstant = nameof(MyConstant);
  You might feel safe because if you change the value of the constant, at runtime all assemblies that reuse your constant will get the new value. But think again, because this will copy the value of the string into the assembly that uses the attribute:
  [SomeAttribute(YourAssembly.MyConstant)]
class TheirClass { }
  To follow assembly metadata rules, this becomes in the metadata:
  [SomeAttribute("MyConstant")]
  So that if you later change your constant to:
  public const string MyCoolConstant = nameof(MyCoolConstant);
  The referencing assembly will still have "MyConstant" in the attribute and it will not match.

Conclusion

While magic strings can be a source of errors if used improperly, they can also provide significant benefits in certain situations. When used correctly, they can make your code more readable, maintainable, and robust. The nameof() operator in C# provides additional safety and convenience, particularly when you want the string to track the name of the type or member. However, in cases where the string is defined by a specification and should not change, using nameof() can be hazardous. As with any tool, the key is to understand when and how to use it effectively.

I find it ironic that so many of these same folks who argue the merits of decentralized currency then get mad at the ‘central’ figures behind the coin for not somehow magically driving the price up, after these folks buy into it.

Getting rich quick isn’t among my primary motivators for evangelizing cryptocurrencies. I want to see cryptocurrency take over the economy as the primary form of money, while supporting legacy payments for the phone-less. Debit cards with chips could perhaps one day make phones unnecessary.

Honestly, by the time this vision is reached, I’ll be surprised if any of the cryptocurrencies currently in existence are still around, because none of them measure up to the privacy, scaling and speed that the economy requires. But only by engaging in the cryptocurrencies we have today can we push the economy toward embracing them and motivating continued innovation in that area.

To folks who want to actually contribute to their favorite cryptocurrencies rather than just HODL, here are a few things that I expect would help:

1. Accept cryptocurrencies at your business.
2. Go out of your way to patronize businesses that accept cryptocurrency, even if you wouldn’t otherwise shop there. Evangelize to other businesses you patronize to accept cryptocurrency.
3. Write software that improves the experience for handling cryptocurrency, particularly for businesses.
4. Lobby your government representatives to enact legislation that promotes cryptocurrencies. In the U.S. particularly, ask them to legislate that cryptocurrencies should be considered currencies instead of securities for tax purposes, and to write any other laws necessary to help businesses feel comfortable transacting in them. Emphasize the importance of privacy coins.