从映射的驱动器或共享文件夹运行.NET程序 - 优点/缺点

Question

对于某些人来说，这可能是一个愚蠢的问题，但是从共享驱动器运行Windows Forms .Net应用程序的优点/缺点是什么。直到最近，我甚至不知道这是可能的。从研究看来，.Net 3 SP1允许这种行为（不需要任何安全更改）。

我很好奇任何并发问题或可伸缩性。

此外，我假设.Net仍然需要在每个客户端上运行共享驱动器的应用程序。任何帮助表示赞赏。

Answer 1

我们有许多用.Net编写的控制台程序，可以进行夜间批处理。这些程序“活着”在通过映射驱动器访问的SAN上。由于我们仍然使用.Net 2.0，处理服务器必须专门配置以允许这些程序运行，当然处理服务器需要安装该框架，但是否则它的效果很好。 .Net3.5sp1甚至可以修复特殊配置。

现在，这种情况可能与您的想法有所不同。如果您想将应用程序部署到共享文件夹，以便许多不同的用户可以访问它，这是一个坏主意。如果你写入与应用程序相同的文件夹中的任何数据文件（无论如何都是一个坏主意，但人们总是这样做），那么所有用户都会共享（并锁定）这些文件。此外，当前运行该程序的任何用户都会导致文件系统在程序文件上放置一个锁，可能会使您无法部署更新。如果你想这样做，.Net提供了一个名为ClickOnce的优秀系统来支持将应用程序部署到网络共享。

Answer 2

您需要在每个客户端上安装正确的.Net版本，但没有理由不能从共享驱动器运行，我们在此处和客户端没有问题，只要用户有权访问该共享。

Answer 3

并发性和扩展性不是问题，但在最极端的情况下。您只是使用网络共享作为提供组件的驱动器。该应用程序仍在工作站上运行，仅消耗该机器的操作系统资源和CPU周期。与ASP.NET应用程序不同。

如果应用程序本身使用某种共享资源，而非非典型的dbase服务器，那么并发性和扩展性肯定会发挥作用。但是，无论应用程序是否从网络共享运行，情况都是如此。

一个考虑因素：部署更新可能很困难。您必须让所有用户退出应用程序，以便在任何程序集上都没有锁定。将其构建到应用程序中将是明智的。像查找特定文件名的FileSystemWatcher一样简单，将完成工作。