Another thing that caught me on W2k3, 64-bit, recently, is that on some, but not all, systems if I have an application
appname.exe which is C#, .net 3.5 sp1, compiled in AnyCPU mode, but installed to
Program Files (x86), if you get the configuration file path by
var path = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None).FilePath
it may report
appname.config, as opposed to the more usual
appname.exe.config as the file name.
And when that happens, it is not joking -- if your installer puts a file at
appname.exe.config on such a system, your program will not read it. If you manually move the file to
appname.config and restart the application, all will be well.
The internet hasn't been very forthcoming in either cause or remedy -- I did find several copies of a similar issue for 32-bit apps on Vista x64, but no resolution.
There's a similar bug report against .net 3.5 -- but by observation the issue only happens in a minority of cases. The only difference I've spotted between two machines where one shows the bug and the other doesn't is that the bug shows in the one with .net 3.0 and 3.5 sp1 not fully patched up to date -- but the patches don't touch any of the libraries that are likely to be involved (System.Configuration and dependencies).