Ever wondered if applications really have to be written to target servers or containers? Can they be more flexible so that they run anywhere? I recently had to create a Probot application that worked on VMs, containers, and serverless platforms. And I needed to do that without writing multiple versions of the code.

Since it’s the gift-giving season, it seems like the perfect time to wrap up the posts about how to distribute packages. More specifically, how to distribute dependencies and settings with NuGet packages.

Packages are code, too! Like any other code solution, it’s important to be able to test your work. In this post, you’ll learn how to test a custom .NET package that adds ZIP support to the build process.

In my last post, I showed you how to use MSBuild to automatically create a ZIP package for deployment in .NET. Now, I’ll show you how to automate distributing those changes to developers using a NuGet package.

The process of compiling a .NET project and creating a ZIP file for deployment is often more complicated than it needs to be. Most CI/CD systems use a series of commands and external dependencies to build and package the project. This post shows how to use built-in functionality to simplify the process to a single call to dotnet publish.

Ever wondered why some numbers never seem to add up? Or why adding 0.1 and 0.2 doesn’t exactly equal 0.3 in JavaScript? Or why adding two numbers sometimes gives an unexpected value with floats and doubles in C# and Java? It’s time to understand floating point numbers and the magic that makes them operate.

I previously mentioned that it’s possible to force a release build to act like a debug build. To do this, we need to understand how .NET knows when to treat an assembly as a debug build or a release build (hint: it’s not the AssemblyConfiguration attribute!). We also need to understand the options that the runtime provides for overriding the default settings. Time to explore how that process is implemented and the configuration options available for overriding those settings.

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.