【发布时间】：2009-01-13 15:57:09
【问题描述】：
对于你们中的一些人来说，这可能是一个愚蠢的问题，但是从共享驱动器运行 Windows Forms .Net 应用程序的优缺点是什么。直到最近，我什至不知道这是可能的。从研究来看，.Net 3 SP1 似乎允许这种行为（不需要任何安全更改）。
我对任何并发问题或可扩展性感到好奇。
另外，我假设从共享驱动器运行应用程序的每个客户端仍然需要 .Net。任何帮助表示赞赏。
【问题讨论】：
【发布时间】：2009-01-13 15:57:09
【问题描述】：
我们有许多用 .Net 编写的控制台程序，它们在夜间进行批处理。这些程序“活”在通过映射驱动器访问的 SAN 上。由于我们仍在使用 .Net 2.0，因此必须专门配置处理服务器以允许这些程序运行，当然处理服务器需要安装框架，但除此之外它工作得很好。 .Net3.5sp1 甚至会修复特殊配置。
现在，这种情况可能与您的想法不同。如果您想将应用程序部署到共享文件夹以便许多不同的用户可以访问它，那么这是一个坏主意。如果您写入与应用程序相同的文件夹中的任何数据文件（无论如何都是个坏主意，但人们一直这样做），那么这些文件将由所有用户共享（并锁定）。此外，当前运行程序的任何用户都会导致文件系统锁定程序文件，从而可能使您无法部署更新。如果您想这样做，.Net 提供了一个称为 ClickOnce 的出色系统来支持将应用程序部署到网络共享。
【讨论】：
您需要在每个客户端上安装正确的 .Net 版本，但您没有理由不能从共享驱动器运行，我们在这里和客户端都这样做，只要用户没有问题有权访问共享。
【讨论】：
并发和扩展不是问题，但在最极端的情况下。您只是将网络共享用作提供程序集的驱动器。该应用程序仍在工作站上运行，仅消耗该机器的操作系统资源和 CPU 周期。与 ASP.NET 应用不同。
如果应用程序本身使用某种共享资源，而不是非典型的 dbase 服务器，那么并发性和扩展性肯定会发挥作用。但无论应用程序是否从网络共享运行，情况都是如此。
一个考虑因素：部署更新可能很困难。您必须让所有用户退出应用程序，这样任何程序集都不会被锁定。将其构建到应用程序中是明智的。像寻找特定文件名的 FileSystemWatcher 这样简单的东西就可以完成工作。
【讨论】：