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

时间:2009-01-13 15:57:09

标签: winforms .net-3.5

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

我很好奇任何并发问题或可扩展性。

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

3 个答案:

答案 0 :(得分:4)

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

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

答案 1 :(得分:2)

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

答案 2 :(得分:2)

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

如果应用程序本身使用某种共享资源,而不是非典型的dbase服务器,则并发和扩展肯定会起作用。但无论应用程序是否从网络共享运行,都会出现这种情况。

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