Does Operating System matter when building code?

[Cjewett]

Edit: While I've marked an answer it is worth taking a look at the whole thread because both responses offer great information.

Hi all,

Apologies if this is the wrong forum to ask this question. If there is any guidance on who is best to answer this question it would be much appreciated if you shout it out.

We have coupled our CI/CD pipeline and release machines to the same Windows Server version. The belief is that if you build code on Windows Server 2022 then deploying it on Windows Server 2019 might fail in unique circumstances because you didn't build or run tests on the same operating system version. As you can imagine this becomes a pain anytime we need to upgrade CI/CD machines to support technologies outside of the .NET ecosystem because we use the same machines for different technology stacks.

My question is does the operating system impact the build output of the compilation? I'm struggling to see how at the moment. I can see how the operating system might limit which SDKs you can install but would have expected that the SDK is the one that dictates the build output. In other words I'd expect a Windows Server 2022 machine with SDK 7.0.3 build output to be equivalent to Windows Server 2019 with SDK 7.0.3.

If it matters this is all .NET Framework 4.8, .NET Standard 2.0, .NET Standard 2.1, .NET 6, and .NET 7 target framework code.

Thanks for reading!

[svick]

If you're using deterministic mode of the compiler (which should be on by default in SDK-style projects, I think), then all the things that affect the output of the compiler are described here.

Based on that, I think a different OS version shouldn't have a noticeable effect on the produced assembly.

Though you mentioned you don't want to test on different OSes, and the compiler can't help you there: if your code uses any OS-specific functionality, its behavior will of course be different on different OSes.

[jasonmalinowski]

The question here is less the compiler and more the end-to-end build chain. As @svick correctly points out, the compiler itself doesn't care: it is given a set of reference inputs and source files, and spits out a binary. And even it's not operating in /deterministic mode, it's not going to go out of it's way to depend on the OS in some way. And @Cjewett as a good example, the "official" Roslyn binaries we built on a Windows CI, and I don't even know without looking which version it is...and those are the binaries we ship that run in VS for Mac and VS Code (which supports both Mac and Linux). When we're developing we copy binaries from Windows to Mac/Linux all the time.

The way you could get screwed up would be if your build has a COM reference to a Windows binary or something else which might pick up machine state. Assuming you're projects are following the standard patterns of consuming references via NuGet and you haven't customized your build in ways that might have custom MSBuild logic, you should be fine.

[Cjewett]

Thanks for the responses here! Really appreciate it.

We definitely had COM references in the past but we've made an effort to remove those in favor of NuGet references or replacements, so we might have gotten over the hump so that isn't an issue. Good to know it can be a problem so we can double check ourselves there.

Understood on the issues that may arise if we don't test on the target OS to be deployed on. It's something we definitely want to do but lack the infrastructure to do at the moment, but upgrading to Windows Server 2022 opens up some containerization possibilities for us so we can spin up those tests against different OS.

Thanks again! I'll be able to take this back to folks and generate some discussion on our end.