Same source code on two machines yield different executable behavior

Question

Here's the scenario:

A C# Windows Application project stored in SVN is used to create an executable. Normally, a build server handles the build process and creates builds at regular intervals which are used by testing. In this particular instance I was asked to modify a specific build and create the executable.

I'm not entirely sure if the build server modifies the project files, but I know it creates a tag in SVN of the source code it used to compile the executables. Using that tag I've checked out the code on a second machine, which is a development machine. I then compiled the source on the development machine.

When executed, the application that was compiled on the development machine does not function exactly like the one compiled by the build server. For example, on the testing machines a DateTime Parse execption is detected by the application. However, the build machine's executable does not throw any exeptions. If I run the executable on the development machine no exceptions are thrown.

So in summary, both machines are theoretically using the same source code and projects.
The development machine's executable only works on the dev machine. The Build machine's executable works on every machine, including the dev machine.

Are the machine's Regional Settings or Time Zone stored in the compiled executable? Any idea what might cause this behaviour or how to check the executables to find the possible differences and correct them?

Unfortunately, I cannot take a testing machine and attach a debugger to it. As soon as I can I will.

Answer 1

Can you run the program on the build machine under a debugger?

If so, then debug the problem - there's no need to guess.

Have the debugger on the dev machine catch the exception, set a break point at the same place on the build machine. See what's different between the two.

Answer 2

It's possible that the two machines have different versions of an underlying dll that isn't part of your build process. I've seen this happen when distributing services across our internal server farm.

Answer 3

The app uses the Regional Settings of the machine it's running on, and it looks like it is your problem. You can force a thread to use a specific culture by setting System.Threading.Thread.CurrentThread.CurrentCulture and System.Threading.Thread.CurrentThread.CurrentUICulture to a specific value.

Answer 4

I had a similar problem once (except in C++) When I compared the sizes of the compiled executables, they were way off. Unfortunately, after days of searching, the best solution I found was to uninstall VS05 and re-install it.

Answer 5

I've seen different "Regional and Language Options" on XP cause this sort of behavior. Do these match on both machines? Start | Settings | Control Panel | Regional and Language Options...

Answer 6

Why are you using a build server anyways, for C# code, if I may ask?

The build times for C# when I was using it were hardly noticable (<2s). Is the app really that big?

Answer 7

I have a couple questions - do both machines have identical regional settings and where are your error logs? I would hope ;-) you have exceptions being handled and written to disk, event logs .. something to help with problems like this.

Where does the date come from that is being parsed? If it is in your db maybe you have bad data too.

Answer 8

The build system probably makes a release version, while the manual build on the dev PC makes a debug version. The debug version has more error checking in it. See if you can manually build a release version and see if there are still differences.

Answer 9

The same source code rarely if every builds the same program on different computers. You should always assume the programs are different, never expect them to be the same. In an environment like linux with a good package manager and periodic and or random updates, never expect the same source code to build the same program on the same computer either. The higher the language the worse it gets. Building a program for the debugger is drastically different than building for release. The debugger version even without the debugger hides bugs that you wont find until you go to the release build. You basically get to debug the program twice if you rely too much on a debugger environment.