A few weeks ago I went in for some simple tests as we tried to uncover the root cause of a sudden heartburn. With each test I took, we discovered that my condition was substantially worse than it seemed. I was running out of time quickly, and the doctors had to act fast.

If you’re not completely sure about the differences between Debug and Release builds in .NET, you’re not alone. Like PDBs, there’s lots of myths and half-true stories coloring our views. Most developers know that they use debug builds when they are creating code. But what is .NET really doing that’s so different? They know they should use release builds for production, but they don’t necessarily understand why. Think the code is better optimized by the compiler? That’s not entirely true (or at least it’s not true if we’re speaking about Roslyn or MSBuild). This post will explore what’s happening under the covers with Roslyn and the just-in-time (JIT) compiler.

In part three of our discussion of PDBs and debugging, we explore an improvement to the debugging experience: SourceLink. Instead of using the symbol server tools to source index our PDBs, we can use an open source, standardized approach to map our symbols back to the files in source control that were used to build our binaries.

It’s not really an exploration of PDBs and debugging without talking about symbol servers. With .NET evolving, has our need for these previously essential systems changed? In this post, we’ll explore what a symbol server is, the role they fill, and their strengths and limitations.

Years ago, John Robbins examined the details of PDB files in PDB Files: What Every Developer Must Know. Since then, a lot has changed about .NET. Despite that, most developers still lack an understanding of how PDBs work or why they are so important. Most times, I see teams trying to prevent PDBs from being created in release code; this is a sure path to future problems. In this post, I’ll provide updated details on the nature of PDBs and how they work.

For certificates to work, we need a system of trust. We need to know that each certificate is valid and was properly issued. This is the role of the certificate authorities (CAs). In the second part of this series, we’ll explore the role of CAs and how certificates are validated. We’ll also look at creating a private CA using a self-signed certificate.

Despite decades of use, certificates tend to be a mystery to most developers. At their root, they are largely more than a collection of name-value pairs and a public key. The majority of people that work with certificates regularly often run into situations where they need to understand the details of how they work. In this post, we’ll dive into the basics and learn what’s in these files.

Most package management systems support some kind of “universal artifacts” storage. Azure Artifacts supports “universal packages”, Artifactory supports “generic repositories”, and Nexus has “raw repositories”. But what about GitHub? From all appearances, it would seem this is an oversight. Although not explicitly documented, it turns out it’s fully supported.

If you’ve ever wanted to integrate an external system or execute parts of the CI process asynchronously, the GitHub Checks API can provide a way to make that happen. In fact, you can even use Checks to allow two workflows to work together, no waiting or polling from the runner required. Today I’ll demonstrate how the API works and provide two workflows that demonstrate how to build a working GitHub Check.

Most people don’t realize that the humble pull request orchestrates surprisingly complex activities behind the scene. GitHub creates test merges and simulated merge branches to test and validate what would happen if the changes were merged into the target branch. This is more complex than most people realize, and it leads to a number of different SHAs being provided to the GitHub workflow. It’s time to understand these SHAs, their purpose, and how to find them.