我们试图一次推送更新到多个服务器，我的经理发现可以重命名正在运行的.exe文件。 使用这些知识，他想重新命名一个正在运行的exe文件，并复制一个新版本的exe文件，这样任何运行foo.exe的内存拷贝的用户都可以正常运行，任何打开指向foo.exe的快捷方式的用户都将得到一个新的副本应用更新。
我想我需要澄清一下，他不希望旧的副本神奇地更新，他只是希望他们继续运行旧的副本，直到他们再次打开EXE，在这种情况下，它会打开新的名称旧的。
它有时会抛出一个exception，该文件正在使用他的程序，但如果他尝试在一个循环中重命名，它将最终成功。 在我的机器上，我还没有能够让它在一个循环中工作。
我的第一个也是主要的问题是：这样做是否可以接受？ 重命名正在运行的可执行文件是否是一个有效的场景？
其次，如果这是一个有效的情况，那么如何可靠地做到这一点？ 我们目前的想法是尝试使用File.Move（C＃）进行重命名的一堆，如果它不起作用，然后写出一个错误日志，所以可以手动处理。
一名飞机机械师和一名外科医生在一家酒吧见面。 机械师说：“你知道，我们基本上是一样的工作，我们把破碎的东西拿出来，把新的更好的零件放进去。” 外科医生说：“是的，但是当你修理时，你不必保持飞机飞行！”
尝试通过在应用程序运行时移动文件来更新应用程序似乎与试图在飞行中修复飞机一样危险。 可能？ 当然。 大大增加了发生崩溃的风险？ 是的。
如果您要更新的应用程序是托管应用程序，请考虑使用ClickOnce部署 。 这样，下次有人运行应用程序时，如果有新版本可用，它将被复制下来并自动安装。 这比在应用程序运行的时候更加安全和愉快。
不，这是不可接受的。 不要这样做。 这不是有效的部署机制。 这应该是你的或他的第一个线索：
它有时会抛出一个异常，该文件正在使用他的程序，但如果他尝试在一个循环中重命名，它将最终成功。
无论如何，这将无法正常工作。 他的理论是错误的：
使用这些知识，他想重新命名一个正在运行的exe文件，并复制一个新版本的exe文件，这样任何运行foo.exe的内存拷贝的用户都可以正常运行，任何打开指向foo.exe的快捷方式的用户都将得到一个新的副本应用更新。
具体来说，内存中的副本不会因为它具有相同的名称而被新的可执行文件自动替换。 之所以允许您首先重命名可执行文件，是因为操作系统没有使用文件名来查找应用程序。 原始的可执行文件仍然会被加载，并且会保持加载状态，直到您明确地卸载它并加载新的，被修改的可执行文件。
请注意，甚至像Chrome和Firefox这样的现代网络浏览器，如果它们的超级花式自动，在后台，从来没有人知道它们存在，更新程序仍然需要关闭并重新启动应用程序才能应用更新。
不用担心在这里拍摄信使 您的客户和技术支持部门更有可能首先向您开枪。
见1号。
如果您使用的是Windows Vista / server2k8或更新版本，则可以使用mklink创建包含应用程序的文件夹的符号链接，然后从“符号链接文件夹”中启动应用程序，然后在更新时创建一个新文件夹，例如“AppV2”并将SymLink更改为该文件夹，所以下次用户重新启动应用程序时，他会从新文件夹中启动它，而不会注意到。
重命名打开的文件总是一个不错的选择！
但总的来说，我会想到一个更好的部署策略，因为如果你需要使用这种“黑客”，总是一个混乱的情况。 我不知道你的应用程序，但ClickOnce可能是一个开始点，因为你可以配置它来检查每一个开始更新…
在我们的组织中，我们通过使用两个发布文件夹（EXE_A和EXE_B）来解决更新问题。 我们还有一个名为EXE的发布文件夹，它只有链接ALL，指向用户运行应用程序的EXE_A或EXE_B。
当我们发布该程序的新版本时，我们将其发布到链接中未引用的文件夹，然后更新链接（EXE）。 这样，您就不会陷入用户持有应用程序/程序集的异常。 另外，如果用户想要运行更新的版本，他所需要做的就是关闭/重新执行EXE文件夹中的链接。