一、从服务器载得文件的方式:
1、HTTP//如果用户反编译时,会看到下载地址,对安全不利
2、FTP//如果用户反编译时,会看到下载地址,对安全不利
3、SOCKET//比较复杂
二、升级方式:
1、比较服务中SETUP.EXE的版本与本地程序.EXE的版本,需要更新则下载,下载完自动运行SETUP.EXE进行更新。
这样做的缺点:可能打包成SETUP.EXE里的有些文件并没有改变,但重复下载且安装。且每次打包时忘记变化版本信息,用户则得不到更新。
这样做的优点:只比较一个文件的版本,方便比较。
2、比较服务中,与本程序相关的所有文件的大小,发现改变的,下载改变的文件,并覆盖本地的文件。
这样做的缺点:有些EXE文件,如果你改动不大,生成EXE后,文件大小不会改变(经测试确实如此),这样做会得不到更新。
这样做的优点:只更新文件大小变化的文件,减小网络流量和更新时间。
3、比较服务中,与本程序相关的所有文件的最后修改日期,发现改变的,下载改变的文件,并覆盖本地的文件。
这样做的缺点:EXE文件,重新生成最后修改日期会变化,下载到本地,最后修改日期不会被本地机器修改,这样可以得到更新,但非EXE的文件,如:JPG,DOC,XSL等,下载到本地后,本机会修改为当时的时间,所以造成本地的修改时间比服务器相应文件的修改日期还要更新,所以第二次就不会得到更新。且有些服务器的文件时间到本地处理时,会舍弃秒,而造成判断不准。
这样做的优点:只更新最后修改时间变化的文件,减小网络流量和更新时间。
4、对比较EXE、DLL有版本的文件,比较版本,其它文件则比较大小或最后修改时间。
缺点:同样是,修改后忘了改版本号,用户则得不到更新。
5、在服务器中,下载的区域做个INI文件,对修改后的文件在INI文件中做标示,用户先比较这两个INI文件,相同的部分,不下载,不同的则下载。
缺点:对变化的文件,每次还得在INI里做标记,如果有一次忘了,则...
优点: 比较简单,减小网络流量和更新时间.我目前能想到的方式就是这些,不知哪种方式最好,最利于维护\操作.我现在用得是FTP,比较文件大小.

解决方案 »

  1.   

    将文件版本信息保存到配置文件中,比如ini,xml后者注册表。升级程序单独做一个。
      

  2.   

    这样做,每次修改软件版本,且还得维护INI文件,麻烦呀.
    非EXE\DLL的文件,如何做?因为这种文件没有版本信息?
      

  3.   

    如果你只是发行一个exe,那么exe自删除,比如你的程序叫1.exe,先将新版本下载下来,名称叫2.exe,生成一个删除脚本,1.exe运行脚本并exitprocess退出,脚本删除1.exe并将2.exe重命名为1.exe,1.exe删除脚本,这是一种野鸡方法,当然网上有一些注入其他进程,依靠其他进程进行删除的方法相对会简单不少,不过我没去试过,也可以尝试下。
    如果是版本更新比较频繁的,比如游戏啊什么的,这种就不适合更新exe。
      

  4.   

    哦,我看成是方式了,非EXE/DLL你就直接强制都更新了呗。
      

  5.   

    问题在于,你的目的不就是想让用户升级嘛,怎么还涉及保密了,这是分开解决的,完全可以做到,非授权用户不能运行exe。
      

  6.   

    我做过的处理方式就是HTTP,通过比较版本来升级。升级的流程按照一个配置XML。
      

  7.   

    不会XML
    到底用:
    一个SETUP.EXE
    比较文件大小
    比较EXE,DLL文件版本
    比较文件最后修改时间
    哪种呢?
      

  8.   

    每个涉及到的文件做个hash运算。然后比较这个结果……
    这样,只要有不同了,就可以更新了。
    问题是,如果管理员在服务器端误操作,把一个(批)旧的文件放进去了……
      

  9.   

    exe与dll自身就有版本,在升级的时候判断如果要升级的比现在的还旧,提示服务器数据有错误,并反馈就行了。
    或者你在升级服务器的时候,就执行一个保护机制。
      

  10.   

    主要看你要更新的内容多不多如果不多,并且文件都是单独的,可以弄个文件列表,里面配上文件的hash,更新的时候先下载列表如果要更新的多,就得做更新补丁了,定义版本号