当毕设功能基本实现,程序接近尾声时,应用程序的部署就成为了一大难题!怎样才能让用户很方便的部署呢?制作安装程序,让用户直接执行一个setup.exe!
Visual Studio 2005功能确实强大,这些都完全为您想好了。直接在解决方案里添加一个windows安装项目,就可以以图形化的方式创建安装程序了。感叹啊!难怪现今是微软的天下~^_^
由于我的程序包含一个winform程序和一个windows service~,制作winform的安装项目时,很简单。好像就是一个打包压缩的过程。但这个windows service程序咋办?能在安装程序里实现自动注册吗?
安装项目中有自定义操作,里面可以添加exe,dll,vbs等应用程序集。首先我想到的第一个方法是,写个bat文件,在里面直接调用installutil.exe来注册服务。这个方法面临两个问题:第一,如果用户没设置环境变量,让cmd自动加载.net work的sdk的话,如何在不同版本的.net work下找到installutil的路径?第二,如何获得用户安装程序时的路径,进而确定服务程序的路径?
看来以上这种方法实现起来有点困难。百度吧,能否找到不用installutil.exe来安装服务的办法!找到啦,有人写了个程序,通过调用windows的API来实现。我想:如果利用这个程序来实现,至少也得传一个服务程序的路径参数进去才行!
……
百度,google了好多资料,都让用自己写程序的方式来实现。难道微软没想过,服务程序的安装和部署吗?不可能啊!应该有一些简单的方法,只是我没找到而已。后来问了一些前辈,看了项目组以前的一个实例程序,发觉里面根本就没有调用什么程序,只是在“自定义操作”里,添加了个“主输出来自servicename(活动)”。我也照着添加了服务程序的主输出——重新生成——安装,晕,居然这样就可以了。
回过头来发现,其实自己写的服务程序主体,都在service1.cs里面。而ProjectInstaller.cs里面ServiceInstaller类,可能就提供了安装,卸载服务程序等方法。而installutil.exe和安装项目里,只是调用了这些方法来实现安装等操作。原来咱们能想到的,微软都“考虑好了”,果然编程是在向一种“傻瓜式”的方式转移,也难怪底层技术全被国外巨头垄断。原来,咱们都习惯了被人家牵着鼻子走……
完全不知所云,结束!!!