我有一个.NET 4 WPF需要在公司网络内运行的应用程序。
该应用程序不使用本地文件（它确实有一个app.config文件，但它只包含一些connection strings）用于数据存储，但中央SQL server数据库。
将应用程序文件放在共享网络驱动器上并仅为每个用户创建应用程序可执行文件的快捷方式有哪些缺点？
我在以下链接中找到了有关该主题的一些数据，但我无法得到明确的答案：
从映射驱动器或共享文件夹运行 .NET 程序 - 优点/缺点 https://stackoverflow.com/questions/439515/run-a-net-program-from-a-mapped-drive-or-shared-folder-pros-cons
从映射驱动器或共享文件夹运行 .NET 程序 https://stackoverflow.com/questions/359978/run-a-net-program-from-a-mapped-drive-or-shared-folder
http://support.microsoft.com/kb/832742 http://support.microsoft.com/kb/832742
如果知道使用这种方法时东西是如何工作的，应用程序文件是否被复制到本地用户或发生其他情况，那就太好了？
我已经使用我们内部运行的应用程序完成了此操作。
根据设置，.NET 可能会简单地拒绝从网络驱动器加载或执行程序集，因为该可执行文件可能存在安全风险。因此，当您的程序尝试使用 DLL 时，它可能无法运行或可能引发异常。
仅仅拥有网络上可执行文件的快捷方式的另一个缺点是当您部署更新时。这些文件很可能会被锁定，您要么必须去每台计算机并确保软件已关闭，要么删除服务器上的用户锁定，这可能会很痛苦。第一次部署后，我很快就发现了程序中的一个错误，并且立即发现了这个问题。躲开它。
我在网络上的一个众所周知的位置（可配置）拥有运行该程序所需的所有文件。当新用户需要该应用程序时，我只需将所有内容复制到他们计算机上的某个位置，并在桌面（或开始菜单，可能是启动文件夹）上创建一个快捷方式供他们使用。然后，程序会不时自动查看该目录中的一些元数据（版本信息），如果较新，则会自动更新。
除了应用程序可执行文件之外，这还需要单独的可执行文件进行更新，以避免执行卷影复制和重新启动。我的应用程序中发生了以下基本事情：
- 该应用程序确定网络驱动器上是否有更新版本。
- 如果是这样，它会更新更新程序可执行文件，然后使用应用程序的进程 ID 作为命令行参数启动更新程序，然后自行终止。
- 更新程序会等待传递给它的进程死亡后再继续（因此应用程序可执行文件不会被锁定）。
- 更新程序更新应用程序文件。
- 然后更新程序重新启动该应用程序。
我还没有遇到这个计划的任何问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
