假设在客户端上安装并注册了 *.dll、*.ocx 等组件，那么就可以将 *.exe 和一些相关文件放在文件服务器上。要启动该应用程序，客户端桌面上有运行 的链接\\fileserver\AppPath\exe。
您同意这样的布局吗？如果“客户端”是终端服务器，“客户端”是指终端服务器群，情况会怎样？
答案1
我不介意在文件服务器上放置可执行文件。它们不在那里执行，而是在客户端执行，因此不会比该服务器上的任何其他文件带来更大的风险。毕竟，这些文件只是作为文件而不是可执行程序提供。
对于终端服务器来说，情况就不同了。可执行文件在服务器上运行，而不是在客户端上运行。但是，由于终端服务器就是为该角色而设计的，因此除了确保使用正确的方法安装需要安装的任何应用程序（而不是简单地复制）之外，不会出现任何问题。
答案2
如果该应用程序就像一个.exe文件一样简单（可能带有一堆支持文件，它们也可以驻留在同一个目录中），并且不需要在客户端上进行适当的设置，这可以完成并且运行良好；它还有一个额外的好处，就是不必担心在每个客户端上部署/维护/更新应用程序。
当然，如果客户端计算机失去网络连接和/或文件服务器出现故障，该应用程序将无法使用。
答案3
角色分离是这里要应用的一个重要概念。如果您有一个托管用户文档的网络共享，您可以根据它托管的文件类型以及用户可能需要在一天中的什么时间访问它等因素对该共享应用某些备份、可用性和安全方法。您还知道，如果您必须在白天将托管它的服务器离线进行维护，您只需通知用户在此期间关闭所有打开的文档即可。
现在假设您已将一些软件添加到该文件共享中，用户可直接从共享中运行这些软件。突然之间，您要备份程序数据和用户文件数据。如果您需要关闭服务器进行维护，您现在会面临额外的麻烦（如果在应用程序运行时服务器离线会发生什么？）。这只是众多示例中的一个，您对管理程序的需求和管理文件共享其余部分的需求可能会发生不同的冲突。您无法总是提前预测这些冲突，但这是经常导致管理麻烦的事情之一。
因此，如果功能和角色的特征不同，或者将来可能出现分歧，则应尽可能将它们分开。这样更优雅、更易于支持，而且不会出现令人不快的意外。
举一个真实的例子：在我之前工作过的一家公司，我们有一个通用的文件和打印服务器，并且我们为群件运行 Lotus Notes/Domino。所有用户的 Lotus Notes 安装都托管在文件和打印服务器上的文件共享中，并直接从中运行。我相信这样做最初是为了能够升级一次 Notes，并让所有客户端自动更新。也许在某个时候这是可行的。
但实际情况是，一个网络故障（可能一周一次）就会使所有 Notes 用户无法使用电子邮件，并在共享上生成一个锁定文件，需要管理员手动删除。当“电子邮件中断”时，人们确实会注意到。软件加载也很慢，尤其是早上 150 个用户同时尝试加载一个 .exe 时。最糟糕的是，Notes 升级仍然需要访问每台 PC。最终的净收益为零或负数，尽管我猜想这最初看起来是一种节省时间的好方法。
至于您的具体问题……您这样做到底想达到什么目的？如果您的 .exe 是内部创建的，并且经常更新，而您的开发人员只是想要一种更快的方式来发布他们的更新……请小心。在用户仍在访问 EXE 时将其替换掉可能会导致麻烦和数据不一致。此外，在终端服务器上加载应用程序应该以特定的方式进行，使用设置用户/安装安装之前在 TS 上执行命令，然后设置用户/执行安装并准备运行时。绕过此过程可能会导致不可预测的结果。
答案4
根据应用程序的构建方式，这可能比看起来要棘手得多，单个 exe 可能需要一些帮助才能使其从非本地驱动器运行。请参阅此关于 .Net 代码访问安全性的 Stack Overflow 问题讨论您可能面临的一类问题。
有一些非常强大的应用程序流式传输解决方案可以为您提供相同的易管理优势（Citrix XenApp 可以做到这一点，VMware ThinApp ......）。这些解决方案为复杂的应用程序提供了可管理的解决方案，但需要付出一定的代价。对于运行良好的简单应用程序，您的解决方案可能很方便，但您必须小心运行良好的部分。