假设在客户端安装并注册了* .dll，* .ocx等组件，就有可能将* .exe和一些相关的文件放在文件服务器上。 要启动应用程序，客户端桌面上的链接将运行\\fileserver\AppPath\exe 。
你会同意这样的布局吗？ 如果“客户”是terminal服务器，“客户”是指terminal服务器？
我在文件服务器上有可执行文件没有问题。 它们不在那里执行，它们在客户机上执行，所以不会比其他可能在该服务器上的文件造成更大的风险。 这些文件毕竟简单地作为文件，而不是作为可执行程序。
谈到terminal服务器，这是另一回事。 可执行文件然后运行在服务器上，而不是客户端上。 但是，由于terminal服务器是专门为此angular色devise的，所以除了确保需要安装的任何应用程序（而不是简单复制）都使用正确的方法进行安装之外，不会有任何问题。
如果应用程序像一个单一的.exe文件一样简单（也许有一堆支持文件也可以驻留在同一个目录中），并且不需要在客户端上进行适当的设置，这可以很好地完成。 它还具有不必担心在每个客户端上部署/维护/更新应用程序的额外益处。
当然，如果客户端计算机失去networking连接和/或文件服务器closures，应用程序将无法使用。
angular色的分离是一个重要的概念在这里适用。 如果您拥有托pipe用户文档的networking共享，则可以对该共享应用特定的备份，可用性和安全方法，具体取决于所托pipe文件的种类以及用户可能需要访问的date。 您还知道，如果您必须在白天将服务器托pipe在离线状态才能进行维护，则只需通知用户在此期间closures所有打开的文档。
现在考虑你已经在文件共享中添加了一些软件，用户直接从共享中运行。 突然之间，您将在用户文件数据旁边备份程序数据。 如果您需要closures服务器进行维护（如果服务器在应用程序运行时脱机，会发生什么情况？ 这是许多的一个例子，你的需要pipe理程序和您的需要pipe理文件共享的其余部分可能会有不同的冲突。 你不能总是提前预测这种冲突，但这往往是导致行政头痛的事情之一。
所以这就是为什么你应该在任何可行的情况下将function和angular色分开，如果它们的特征不同，或者将来可能会分歧。 它更加优雅和可支持，并没有那么讨厌的惊喜。
对于一个真实世界的例子：在我以前工作的一个公司，我们有一个通用的文件和打印服务器，我们运行Lotus Notes / Domino作为群件。 所有用户的Lotus Notes安装被托pipe在文件＆打印服务器上的文件共享中，并直接从它运行。 我相信这是为了能够升级Notes一次，并让所有客户端自动更新。 也许有一点这工作。
但情况的真实情况是，一个星期一次的networking昙花一现，会使每个Notes用户不能使用电子邮件，并在共享上生成一个locking文件，这需要由pipe理员手动删除。 人们真正注意到“电子邮件closures”时。 该软件加载速度也很慢，特别是当你有150个用户同时试图加载一个.exe的第一件事。 最重要的是，Notes升级仍然需要访问每台PC。 净收益最终为零或负值，尽pipe我原先认为这看起来是一种节省时间的好方法。
至于你的具体问题……你究竟想通过这样做达到什么目的？ 如果您的.exe是内部创build的，经常更新，而您的开发人员只是希望更快地发布更新，请小心。 在用户仍然访问的时候换出一个EXE会导致头痛和数据不一致。 此外，在terminal服务器上加载应用程序应该以特定的方式进行，在安装前使用set user / install命令在安装前进行设置，然后在安装时设置用户/执行并准备运行。 绕过这个过程可能会导致不可预知的结果。
根据应用程序的构build方式，这可能比看起来要复杂得多，只是一个exe文件可能需要一些帮助，以允许它从非本地驱动器运行。 请参阅.Net代码访问安全性的堆栈溢出问题，了解您可能遇到的一种types的问题。
有一些function非常强大的应用程序stream式传输解决scheme，可以为您提供同样轻松的pipe理优势（Citrix XenApp可以做到这一点，VMware ThinApp ..）。 这些为复杂的应用程序提供可pipe理的解决scheme，但需要付出代价 对于performance良好的简单应用程序，您的解决scheme可能非常方便，但您必须小心谨慎。