I have a game written in XNA, and I use ClickOnce installers to distribute the game to testers. I keep once computer as a test machine which does NOT have development environments installed, so that I can test the installed version.

We've found a reproducible bug in our game, but the bug ONLY occurs on the non-development machines that use the ClickOnce installer.

The bug is related to some of our code for moving around 3D objects and is not tied to Networking or GamerServices.

Are there known differences in the ClickOnce runtime and the version on dev? Are there any best-practices for debugging something like this?

It sounds like your bug is in the game and not the installer. What makes you think it's related to the ClickOnce? Have you tried just building the game and copying the files manually? Does the bug still occur in this scenario? If so, it's unrelated to the ClickOnce and you'll have to install some kind of debugger to figure out what's wrong.
–
Richard Marskell - DrackirDec 14 '12 at 5:46

A good way to debug this kind of issue would be to have logs that you can activate on-demand, so when someone faces an issue you can just ask them to activate the logs, reproduce the issue and send you the log file.
–
ZonkoDec 14 '12 at 22:40

2 Answers
2

Have you checked that the assemblies referenced by your program are actually installed via the ClickOnce installer ? It could be that the test machines have this installed by default (such as the XNA Framework) but the non-development machine does not.

A way to check this would be to have a look at your solution and check that all the assemblies that you reference have Copy Local set to True in their properties. Also check the install directory to ensure there are no differences between that which are being installed on the test machines and the non-development machines.

Also as a side note, if the game isn't crashing out completely (as I would imagine it would if it was looking for an assembly that didn't exist) then it could be that the non-development machine is loading an old version of an assembly. Check the machine for any cached versions of those that you use and clean them out.

A final step might be to log onto your non-development machine as a different user. As far as I understand, ClickOnce installs per user rather than per machine, so you might get a 'clean' install if you try that.

thanks! It turned out the problem was that the two computers were rounding floating points slightly differently, but it was helpful to check "Copy Local" so that we felt more assured that the libraries were similar.
–
Sean ColomboDec 15 '12 at 1:10

@SeanColombo please select this as the correct answer if it solved your problem. Thanks.
–
ashes999Dec 15 '12 at 1:38

@ashes999 I don't think it's the correct answer (meaning that if someone searches for the same problem, the answer that i put about floating-point rounding is more likely to help them), but I'd rather give him the points (don't want to give myself points obviously). I'm kinda new here (and more used to wiki systems where you don't really have points) so I'm not sure what the best way to do this is.
–
Sean ColomboDec 15 '12 at 5:58

1

@SeanColombo the way it works is you select the right answer as the one that worked for you personally; people will up-vote the ones that worked for them or are "better," so a useful general answer may well bubble up over the accepted answer. It's all good.
–
ashes999Dec 15 '12 at 15:04

This doesn't really make sense. Even with radians, such a small change shouldn't affect rotation by much. Maybe you should consider using degrees instead, but that'll just hide the problem.
–
ashes999Dec 15 '12 at 15:05

@ashes999 the reason it affected rotation so much is that we passed it into Math.Acos() which returns NaN if the number is < -1. So sometimes it was returning NaN when the number was -1.00000000001, even though logically we wanted the same result as when we passed in -0.999999999. We just added an extra case to change the default value (for when Acos returned Nan) based on the sign of the input. So our result defaults to Math.PI for negative inputs to Acos(), and defaults to 0, for positive inputs to Acos().
–
Sean ColomboDec 15 '12 at 18:35

Mind providing more details about how exactly You managed to check that?
–
RekinFeb 6 '13 at 22:52

@Rekin I used the debugger on my PC and Xbox and stepped through, very painstakingly and where it started giving differing results (at this Math.Acos() I "watch"ed the variables and stepped through until I found that the numbers were rounded differently & took the execution to different branches of code.
–
Sean ColomboFeb 7 '13 at 2:45