Error when rolling out my software revision to terminal sessions instead of desktops?

I'm doing some maintenance on some software originally built by my predecessor at the company (who has since moved on to greener pastures). I'm currently rolling out a new version of the software.

At this company, the installation procedure is basically to just shove 开发者_运维问答the /bin/Release directory out into our automated program updater's magic directory, allowing it to automatically copy the contents of that directory over to the local /Program Files/ and let the magic happen. The magic always seems to happen, so there's no big issue, there, although it does weird me out somewhat, after many years of .msi installers...

Anyway, rolling out the new software went fine on two of our file servers, but rolling it out into the third and final location went a bit differently.

The third section of the company doesn't use the auto-rollout software. They all use Windows' Remote Desktop Connection software to run software directly on the server.

So I go along to the server, check that the current version is working (which it is), back it up, etc. then copy the exact same software which works just fine on all of our other machines.

The new software now fails to play nice with the third-party libraries it's using (Crystal Reports and IBM Informix integration), even though those libraries are installed in the same location, and at the same version, on all of the PCs, the development machine included.

The old version of the software accessed the exact same external libraries and it worked fine. There's no special build configuration for the terminal server, either, as far as I can tell.

Can anyone think why these DLLs would now no longer being accessed correctly by the program? I've tried copying the program on the server back to my PC and it works fine. I just can't see that this is directly related to the Crystal Reports or Informix connectivity software, but I can't see what on earth it might actually be.

EDIT: Attempting to follow 0xA3's suggestion, I tried to switch the target platform of the application, and discovered some usercontrol DLLs, which are referenced by the program. I'm currently trying to recreate these components, because changing the target platform stops the DLLs from working.

As there is not much detailed error information to start with I would make a blind guess:

The operating system on the terminal server might be a 64-bit OS whereas the other machines are 32-bit versions of Windows.

At the same time the built target of the program has been changed from x86 to AnyCPU.

See if that is the case and if so change it back to x86.

If it is not the case you need to do some more analysis to see what actually goes wrong. Are there any exceptions thrown when accessing the third-party library? Any particular errors appearing in Process Monitor?

Last but not least: Have a look at your source code repository and see what has been changed as compared to the previous version.

Look at the situation logically:

Has the 3rd section of the company used this software before with success, using Remote Desktop?      
If yes
     what changed between versions?  
If no
     what is the difference between this environment and the other environments 
     that can use the old version with success, because the difference is likely environmental.