记得去年来这边时，曾面过一家公司，要做WPF项目，当时问到“如果让你做一个安装程序，如何实现更新？说下思路就行”，当时我回复的是文件有更新时从服务器下载最新dll，覆盖到本地目录即可。那个时候以为很简单，现在自己接触到以后，发现这里吗的细节还挺多，因此记录一番。
从服务器下载最新文件更新到本地，这很简单，通过版本号控制也好，其他方式比较也好，实现起来不难。但是我说下我遇到的场景：工具改名！
背景：xx年xx月xx日，工具【某工具A.exe】改名为【某工具B.exe】，客户自动升级以后，用不了了，一直重复升级。
原因：工具每次启动时检测服务器版本号，如本地version < 线上version，则下载zip到本地进行覆盖更新，然后重新启动exe。
上面这套升级逻辑用了很久，一直没有出过问题，直到8月份我改了工具的名字，问题就来了！
重复升级的原因是【某工具A.exe】启动时下载新包，新包里是【某工具B.exe】，但是更新完毕后启动的还是【某工具A.exe】，所以一直重复升级。
“聪明的朋友”可能很快就发现了，那我更新完毕以后启动【某工具B.exe】不就可以啦？yes！就是这样！...那么怎么写代码呢？
// 1、下载升级文件 // 2、覆盖本地文件 // 3、Process.Start【某工具B.exe】
Process.Start【某工具B.exe】，我更新完文件以后直接运行【某工具B.exe】，好像是可以了嗷，代码跑一跑，咦，怎么没有效果？
我们来看文件目录：
// 【某工具A.exe】 // 【某工具B.exe】 // 其他文件...
代码没有效果的原因是因为运行的是A，关于升级的代码在B里面，所以你怎么改他都只会运行A，因为A是旧的代码。
当然，除了覆盖。
所以通常的做法是再来个套壳exe，里面写个A启动B的逻辑，更新文件时，用套壳A覆盖旧的A，这样再次启动A时，就可以启动B了，而不是A一直在那里循环。
这种做法是OK的，不过还不完善，比如安装目录有2个exe，桌面还是旧的快捷方式，用户可以自己手动处理一下，但是如果程序能处理好，傻瓜式操作是不是更方便呢？
升级后，1、删除桌面快捷方式；2、根据新的exe名称创建新的快捷方式；3、删除旧的exe
这里我犯了一个错误，在套壳exe代码里删除旧的exe（最后才发现是自己删自己，无语了），应该在新exe也就是B启动的时候删除A，这样就没问题了。
时间关系，只写到这里。
祝大家国庆快乐！
