I'm rubbing the EmpegBBS genie lamp here, I'm hoping someone might know this one...

I'm in the process of converting our company's Build/CI/CD system from Team City to Azure DevOps Pipelines. One of my tasks is to move our product's main compilation step (which is done with MSBuild version 15.0 aka VS2017) to run on a different set of build agent machines, triggered by a different set of processes.

I'm checking to be sure that the resulting compiled executables are more-or-less the same on the new system as they were on the old system. I know that it's normal for some things to be different, I'm not expecting them to be binary-identical. However, I'm seeing a significant difference which looks like a compiler-settings kind of thing, and I'm wondering if anyone recognizes this particular difference. What am I getting wrong in the compiler settings? I'm worried that this is some kind of canary in the coal mine which indicates I've missed something important in my configuration settings.

I've done a "dump" of a particular DLL in our artifact set using the ILDASM tool, and I see this interesting difference in the "User Strings" section. The Azure DevOps Pipeline build is "baking in" some of the format-strings, whereas the Team City build leaves them separated. An example screen shot from Beyond Compare is attached below, to make my question clear.

Does anyone know what compiler optimization setting controls this thing shown in the screen shot? For example, a command line parameter to MSBuild or something.

Thanks!

Clarifying a few things which I know will come up:

- Both outputs are from a Release configuration, therefore the default compiler optimizations should be "on" for both builds.

- Both outputs are from the same set of source code and project files.

- The version of MSBuild might be slightly different between the two, but they should both be basically MSBuild version 15.

- I tried adding the /deterministic parameter to the command line of MSBuild and it failed, saying that it didn't recognize that parameter.

- I tried adding <Deterministic>true</Deterministic> to the CSPROJ file of one of the modules as described here, and the files still differed in the same way. I'm thinking the flag was simply ignored in the project file.

- Actually I notice that when MSBuild calls out to the Roslyn compiler (csc.exe), it adds "/deterministic+" to every one of them already anyway. Here's an example output (some filenames blurred on purpose):


Though I don't know what the "plus sign" means after the parameter. There are a few parameters with the plus sign after them. Any idea what those mean?

Aha, that's interesting... Looks like the Team City build logs do not show the "/deterministic+" flag on them, and the Azure Pipeline builds do. That's the only difference between the two sets of log outputs. That might be the whole thing. Now I have to figure out where that's controlled, deep in our configuration files somewhere.

Update: Actually, some of the modules have it and some of them don't. The one I was examining didn't have it originally, and when I added the <Deterministic>true</Deterministic>, the parameter showed up and was used in the CSC command line. Yet the files still had the same differences. So back to square one.

Got it.

The solution turned out to be slight differences in compiler optimizations between minor dot-versions of Visual Studio. When I upgraded the VS version on one of the old system's Team City build agents, and ran a build there, its differences from the Azure Pipeline build became very minor.