这里讲的是OpenExpressApp的部署方案。主要使用的是ClickOnce作为实施方案来实现:智能部署和智能客户端。不过,这里的使用方式跟以往的不太一样……
部署概述
OpenExpressApp中,界面是自动生成的。而框架使用者所开发的应用程序(以下简称客户程序),只需要按照特定的格式约定编写自己的业务逻辑模型类,然后与框架一同发布,就可以直接运行并显示出所有的界面了,这样就可以实现比较大粒度的重用。如图:
也就是说,当框架使用者使用本框架时,得到的是已经通过ClickOnce发布好的文件夹,里面有应用程序的.exe和.dll文件,而他们只能在Library和Module文件夹中添加他们自己编写的业务模型类库dll。这样,在开始运行后,框架会自动加载指定的dll并运行客户程序的业务逻辑。(上图中的Module文件夹,也是类似功能,当框架使用者想扩展界面功能时,需要在这里放置自己的界面模块。)
虽然并不是所有的应用程序都适合使用这种模式,但是在一些并不要求界面灵活多变的Windows程序中,这样大粒度的重用,确是提高开发效率的好方法。:)
其它问题
由于使用了ClickOnce来实现智能客户端,所以我们在每次发布框架的时候,都会直接对没有任何业务模型类库dll的程序进行发布。使用过ClickOnce的人就会知道,这样生成的文件夹中,会包含分别以.application和.manifest为扩展名的两个文件。文件中存储了所有发布的文件的清单和它们的的Hash值(本来还会有签名的信息,不过目前在框架中并没有使用。),这样可以防止恶意篡改发布后的程序。
也就是说,框架使用者无法直接把自己编写的业务逻辑类DLL,直接拷贝进文件夹中,同框架一起发布到IIS来实现自动升级。
解决方案
框架使用者可以使用工具:ManifestManagerUtility.exe 对发布后生成的.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:PublishIntranetOpenExpressApp.Host.WPF.application" rem 邮件通知所有测试人员 ……………… …………其它脚本…………
结束语
目前我们现在开发的GIX4项目,由于使用了OpenExpressApp框架,所以它的部署工作正是使用了上面的方法实现的一键部署。这对于实施每日构建,提高开发和测试的效率有很大的帮助。
相关文章链接:
- OpenExpressApp架构-一个信息系统的平台
- 订单示例
- 总体架构的由来
- 平台学习必备知识
- 代码目录说明
- 应用模型ApplicationModel
- 内置支持的模块类型
- 内置支持的属性编辑方式
- 内置支持的列表编辑方式
- 理解核心元素ObjectView
- AutoUI自动生成界面
- Command扩展机制