将我的软件修订版部署到终端会话而不是桌面时出错？
我正在对一些最初由我的前任在公司构建的软件进行一些维护（他后来转向了更好的发展方向）。我目前正在推出该软件的新版本。
在这家公司，安装过程基本上只是将 /bin/Release 目录推入我们的自动程序更新程序的 magic 目录中，使其自动将该目录的内容复制到本地 /Program Files/ 并让魔法发生。魔法似乎总是会发生，所以没有什么大问题，尽管在使用了多年的 .msi 安装程序后，这确实让我有些奇怪……
无论如何，在我们的两台文件服务器上推出新软件进展顺利，但是将其推广到第三个也是最后一个位置的情况略有不同。
该公司的第三部门不使用自动推出软件。它们都使用Windows的远程桌面连接软件直接在服务器上运行软件。
因此，我前往服务器，检查当前版本是否正在运行（确实如此），进行备份等，然后复制完全相同的软件，该软件在我们所有其他计算机上运行良好。
新软件现在无法与它使用的第三方库（Crystal Reports 和 IBM Informix 集成）很好地配合，即使这些库安装在所有 PC 上的相同位置、相同版本上，开发包括机器。
旧版本的软件访问完全相同的外部库并且运行良好。据我所知，终端服务器也没有特殊的构建配置。
谁能想到为什么这些 DLL 现在不再被程序正确访问？我尝试将服务器上的程序复制回到我的电脑上，效果很好。我只是看不出这与 Crystal Reports 或 Informix 连接软件直接相关，但我看不出它到底是什么。
编辑：尝试遵循 0xA3 的建议，我尝试切换应用程序的目标平台，并发现了一些由程序引用的用户控件 DLL。我目前正在尝试重新创建这些组件，因为更改目标平台会阻止 DLL 工作。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于没有太多详细的错误信息，我会盲目猜测：
终端服务器上的操作系统可能是 64 位操作系统，而其他计算机是 32 位版本的 Windows。
同时程序的构建目标也从x86改为AnyCPU。
看看是否是这种情况，如果是，则将其改回 x86。
如果情况并非如此，您需要进行更多分析，看看到底出了什么问题。访问第三方库有没有抛出异常？ Process Monitor 中出现任何特定错误吗？
最后但并非最不重要的一点是：查看您的源代码存储库，看看与以前的版本相比有何更改。
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.
从逻辑上看情况：
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.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.