VB.NET应用程序.重新启动行为-意外结果

我有一个应用程序foo.exe，带有内置的更新程序。它将连接到服务器，如果有更新，则将当前（正在运行的）应用程序重命名为foo.exe.bak，下载foo.exe并调用

应用程序。重新启动
以启动foo.exe，它现在是新版本。这似乎有效。。。大多数时候。我运行它的一台计算机似乎总是关闭新版本，而其他计算机偶尔也会关闭旧版本。通过调用
应用程序的按钮重新启动应用程序。重新启动
，然后显示正确的版本

在此失败的重新启动期间，本地系统上的文件是1.2，服务器上的文件是1.2，但运行的版本是我们刚刚更新的1.1。由于更新程序最近进行了调整，以允许检查DLL更新以及当前可执行版本，因此它现在根据预期版本检查exe文件（1.2）的版本，而不是正在运行的应用程序（1.1）的版本，因此不会因版本不匹配而触发另一次更新。最终，这意味着我的应用程序现在出现了错误的一面，它认为它是更新版本

在调用重启之前，我延迟了1秒。将此值增加到5对纠正问题没有任何作用。
关于
应用程序.重新启动的工作方式，我是否缺少一些东西？
我尝试了
Shell（Application.ExecutablePath）
Application.Exit
，但没有成功-它所做的只是让应用程序退出。是否有可靠的方法关闭我的应用程序并再次启动foo.exe

谢谢

将当前（正在运行的）应用程序重命名为foo.exe.bak

你认为这是如何实现的？Windows将不允许您在任何程序文件当前正在执行时重命名它

大多数想要进行自动更新的应用程序都会有第二个“更新程序”来完成这项工作，主程序会在检测到更新后启动更新程序，然后关闭。更新程序将等待主程序退出，更新任何需要更新的内容，重新启动主程序，然后退出

我还看到主程序负责下载“更新”文件，然后在退出之前启动一个快速.bat文件，其中批处理文件仅重命名内容，然后再次启动程序

但无论哪种方式，如果您试图在*.exe文件仍在运行的情况下更新*.exe文件，您将得到奇怪的结果

另一件值得注意的事情是，对于标准特权用户帐户，“程序文件”文件夹默认为只读。如果您需要最终用户能够更新此文件夹中的文件，则需要在原始安装过程中更改此文件夹的默认权限。
所有这些之后，这是一个时间问题。应用程序在启动时就好像不需要更新一样，然后更新程序会返回一条消息，说“嘿，伙计们！我有一个更新！”这时应用程序已经启动了。
它确实允许这样做。MMF只锁定文件数据，而不是目录条目。此外，如果你的猜测是正确的，那么他早就发现了这一点。我震惊地发现，对正在运行的可执行文件，你能做的为数不多的事情之一就是重命名它。反恶意软件总是让你头痛。它们从来都不像一个不知从哪里出现的可执行文件。那些不太可靠的人会花他们快乐的时间去扫描，让它看起来好像还没有出现。但这不能很容易地解释为什么可以执行.bak文件。当这些操作失败时，请务必大声喊叫，包括用户帐户没有足够的权限重命名或在安装目录中创建文件的情况。这是正常情况，UAC保护c:\program文件。您是否尝试在文件foo.exe上使用
Process.Start（）
，然后从（现在）foo.exe.bak文件简单退出？本质上，避免调用restart。另外，如果可能的话，也可能是ClickOnce的工作。汉斯：在我遇到问题的设备上，在我测试它时，该软件是c:\foo格式的——传统上它没有安装。它正在成功重命名该文件，并将任何新的DLL以及新的可执行文件下载到该文件夹中。如果这是一个权利问题，我希望这些也会失败。我将查看任何反恶意软件交互。我的第一个想法是Application.Restart（）可能正在重新加载正在运行的东西，但这并不能解释它在第二次调用时的行为——它肯定会继续运行。谢谢你，我会试试的，因为我忘记了新的测试方法，所以我选择了Shell进行测试。如果这不起作用，那么我将查看ClickOnce。谢谢