这里讲的是OpenExpressApp的部署方案。主要使用的是ClickOnce作为实施方案来实现：智能部署和智能客户端。不过，这里的使用方式跟以往的不太一样……

    部署概述

    OpenExpressApp中，界面是自动生成的。而框架使用者所开发的应用程序（以下简称客户程序），只需要按照特定的格式约定编写自己的业务逻辑模型类，然后与框架一同发布，就可以直接运行并显示出所有的界面了，这样就可以实现比较大粒度的重用。如图：

    也就是说，当框架使用者使用本框架时，得到的是已经通过ClickOnce发布好的文件夹，里面有应用程序的.exe和.dll文件，而他们只能在Library和Module文件夹中添加他们自己编写的业务模型类库dll。这样，在开始运行后，框架会自动加载指定的dll并运行客户程序的业务逻辑。（上图中的Module文件夹，也是类似功能，当框架使用者想扩展界面功能时，需要在这里放置自己的界面模块。）

    虽然并不是所有的应用程序都适合使用这种模式，但是在一些并不要求界面灵活多变的Windows程序中，这样大粒度的重用，确是提高开发效率的好方法。：）

     其它问题

    由于使用了ClickOnce来实现智能客户端，所以我们在每次发布框架的时候，都会直接对没有任何业务模型类库dll的程序进行发布。使用过ClickOnce的人就会知道，这样生成的文件夹中，会包含分别以.application和.manifest为扩展名的两个文件。文件中存储了所有发布的文件的清单和它们的的Hash值（本来还会有签名的信息，不过目前在框架中并没有使用。），这样可以防止恶意篡改发布后的程序。

    也就是说，框架使用者无法直接把自己编写的业务逻辑类DLL，直接拷贝进文件夹中，同框架一起发布到IIS来实现自动升级。

    解决方案

    框架使用者可以使用工具： 对发布后生成的.application文件进行修改，在清单中里面加入客户程序的dll。最后再一同在IIS下进行发布。如图：

    图中红框处可以添加新的文件引用。在这个工具中，同样可以对application文件中的其它属性进行修改，如Server的Url等。

    这样，虽然可以使程序成功发布，但是却无法实现“智能”。因为ManifestManagerUtility虽然这次计算出新的Hash值，并对.application文件进行更改。但是当框架使用者对客户程序再次进行更新时，由于hash值也会变化，所以客户端就无法获取到更新过的dll。这样还必须再重复一次上面修改.application文件的操作，才能正常发布，这样当然不能算“智能升级”。

    所以我们提供了VersionAdd.exe控制台程序。当客户程序升级后，框架使用者把升级后的dll覆盖上个版本的dll，然后调用此exe实现更新，即可自动维护application文件清单并升级ClickOnce的版本。这些发布工作，只需要编写一个简单的脚本文件来完成就可以了。例如，我们现在正在开发的项目GIX4，原来使用FinalBuilder进行发布，现在换成了一个脚本文件，AutoBuild.bat。它的工作主要是实现：从服务器更新文件，编译，发布，邮件通知等……如：

…………其它脚本……………

rem 更新文件 ……………… rem编译 ……………… rem 版本号增加 VersionAdd.exe -FileName "D:\Publish\Intranet\OpenExpressApp.Host.WPF.application" rem 邮件通知所有测试人员 ……………… …………其它脚本…………

    结束语

    目前我们现在开发的GIX4项目，由于使用了OpenExpressApp框架，所以它的部署工作正是使用了上面的方法实现的一键部署。这对于实施每日构建，提高开发和测试的效率有很大的帮助。