先说一下ClickOnce的使用方法：
先给一个要发布的工程设置安全和签名。然后发布到iis中。当用户访问该iis目录下的.application文件时,就会自动安装整个应用程序。
再说一下我们目前的应用程序。相对还是比较复杂的，分为框架部分和特定应用程序部分。其中的框架部分，以后会作为开源框架发布。由于是AutoUI，框架部分就包含了生成最后客户端运行的exe的工程。而特定的应用程序只需要实现自己的类库和模块（Module）。最后发布的时候，需要把生成好的类库和Module放到exe文件所在目录的子目录Library和Module当中，框架会自动寻找这两个目录中的文件，进行加载。
这时候，我们的发布就比较麻烦了。
先要把框架直接发布好，这样其它团队就可以直接使用。但是其中包括安全和签名，和所有文件hash值。这时候，如果其它使用这个框架的团队进行发布时，必须要把他们自己的类库和Module放入到已经打包好的程序当中。然后使用MS一个开源的工具(ManifestManagerUtility.exe)对已经生成好的.application文件进行修改，把类库和Module添加到这个文件中，这样，客户端在装程序的时候，才会也把这些文件一起安装到客户端中。这时，这个软件也会再次对每个文件生成hash值。
但是，这样直接加了以后，有两个问题。
一是他们在类库和module发布更新的版本时，为了避免再次打开那个MS的软件进行手工编辑，应该实现自动化更新application文件。
二是新的文件生成的hash值，肯定不会和原有的hash值相同。
所以，我只有自己把MS的那个软件的源码给研究完，然后自己写了一个控制台程序实现以上功能。
其中，遇到一个MS比较缺陷的设计，害得我是查了好半天！当直接复制MS程序中的代码：
Manifest.ResolveFiles();
Manifest.UpdateFileInfo();
来进行更新时，老是不能把文件的hash值也一并更新。其原因在于，UpdateFileInfo更新hash值时，是使用每个AssemblyReference对象的ResolvedPath来计算hash，而在ResolveFiles方法里面，这个属性值的计算是调用SourcePath和Environment.CurrentDirectory计算出来的。此时，这个Environment.CurrentDirectory文件夹路径是我的这个控制台程序所在路径，所以并不能正确计算出.application所在文件夹中的文件的路径。找不到文件，自然hash值就更新失败了。
解决方案：
一：在更新前，计算出各个AssemblyReference的SourcePath值，然后再调用ResolveFiles方法。（我使用的是此法，因为MS软件中有现成的方法。）
二：使用ResolveFiles的重载ResolveFiles(string[] searchPaths)指定搜索的文件夹即可。
参考：
继承层次 : ApplicationManifest : AssemblyManifest : Manifest。
