OK, some sage advice (I've done truckloads of multi-platform Windows stuff) that is intended to be constructive, alternatively might be patronising but I can't judge that:Quote:
I am unfortunately going by the server 2008r2 command paths.
1) Ensure you compile your dotNet code for "Any CPU"
2) As Arthur suggested a while back you can run nearly all the native utilities from dotNet code without caring about where they live i.e. just with "gpresult.exe" rather than "c:\windows\system32\gpresult.exe". The process class works for everything I've ever wanted to run and that is a lot, the only issues I've had are the waiting for apps that in turn spawn other apps then terminate variety i.e. inherently more complex.
3) If you must have paths because whatever you're using insists, then everything important tends to be in exactly the same folder on both platforms e.g. "c:\windows\system32\gpresult.exe" gets you to that util on both 32-bit and 64-bit. [On 64-bit, the "system32" folder is where all the native 64-bit utilities and DLLs live]
4) If you do have references to a path beginning "c:\windows" then don't - get hold of the %windir% environment variable to get the actual windows folder path and then append "\system32" or whatever to that.
5) If you have to reference the same full path like "c:\windows\system32" in a lot of places and one basic form class, then have a class-global e.g. systemPath, assign it during initialisation (remembering the %windir" point) and use that everywhere else in your code. If you're Being Very Good[tm] you can have a separate class for this instead of a global, but I wouldn't bother unless I had lots of globals that need to be referenced from several classes.
6) Don't compile for dotNet 4 unless you have a serious requirement for some dotNet 4 feature - I always use the oldest I can get away with because it's bound to be more prevalent (dotNet2 is my minimum and what I mostly target).