8 个解决方案
#1
你看换个思路行不行，把你要升级的文件列表写到一个文件里，安装的时候根据这个文件里的内容去复制文件。
不过呢，这个安装包应该不叫做升级安装包了，完全是一个独立的安装包了吧，升级安装包的话，还是应该用installshield提供的patch、upgrade的做法去实现。
不过呢，这个安装包应该不叫做升级安装包了，完全是一个独立的安装包了吧，升级安装包的话，还是应该用installshield提供的patch、upgrade的做法去实现。
#2
请问eric_alex(ericwang) :
installshield提供的patch、upgrade怎么用呢，可否提个醒？
installshield提供的patch、upgrade怎么用呢，可否提个醒？
#3
>不过呢，这个安装包应该不叫做升级安装包了，完全是一个独立的安装包了吧，升级安装包的话，还是应该用installshield提供的patch、upgrade的做法去实现。
是啊，你这是一个新的安装包了，呵呵
从来没用过瑞星，最近在客户的专网里见它们在 W2K Domain 里做瑞星客户端升级，居然是在启动脚本里从服务器的share folder里copy文件...
汗..
是啊，你这是一个新的安装包了，呵呵
从来没用过瑞星，最近在客户的专网里见它们在 W2K Domain 里做瑞星客户端升级，居然是在启动脚本里从服务器的share folder里copy文件...
汗..
#4
>installshield提供的patch、upgrade怎么用呢，可否提个醒？
从 InstallShield Developer 8.02 到 DevStudio 9 和现在的 X 都能很好地制作补丁。
要提醒的是（我的教训），如果可能用到 Windows 域里，最好用 MSI Project，而非 InstallScript MSI Project。因为一般在域里的权限限制在客户端执行 exe 安装，但 msi 的好处在于还可以支持 SMS 并可以从服务器上远程分发/指派。
呵呵，我做了个自动升级检测模块，现在在考虑加入各种补丁方式实现的支持，做成一个通用的 Update Service。
从 InstallShield Developer 8.02 到 DevStudio 9 和现在的 X 都能很好地制作补丁。
要提醒的是（我的教训），如果可能用到 Windows 域里，最好用 MSI Project，而非 InstallScript MSI Project。因为一般在域里的权限限制在客户端执行 exe 安装，但 msi 的好处在于还可以支持 SMS 并可以从服务器上远程分发/指派。
呵呵，我做了个自动升级检测模块，现在在考虑加入各种补丁方式实现的支持，做成一个通用的 Update Service。
#5
请问楼上二位，patch、upgrade是install shield professional 中提供的工具组件吗？我还不知道如何找到这些工具。InstallScript MSI Project是独立的程序吧？
#6
能者请继续指教！
#7
不是独立的工具，是 InstallShield 7.0 Pro开始加入的一个功能，ISDeveloper 8.0/ ISDevStudio 9.0 比较稳定可用，X 我还没用过 :)
关于 InstallShield Projects：
InstallShield 可以创建三种类型的项目（Project）
1、InstallScript Project
2、InstallScript MSI Project
3、Basic MSI Project
前者完全是 InstallShield 自己的功能实现
后两者基于 Windows Installer，InstallScript MSI Project 在 Windows Installer 基础上提供了一些 InstallShield 自己的扩展功能支持。
Basic MSI Project 完全基于 Windows Installer，制作出来的安装程序完全符合W2K相关标准，因此比较适合在 Windows 域中使用。
InstallScript MSI Project 制作出来的安装程序中可以见到 xxx.msi 文件。该 msi 文件离开了 InstallShield 的 engine 无法独立运行。而 Basic MSI Project 的 msi 文件是可以独立运行的（在域里面就知道好处了） :)
InstallShield 做补丁的机制也与 MSI 补丁有区别。
关于版本升级补丁和热修复补丁：
说到做补丁，也有很多不同的方法
1、很多如网络游戏、瑞星等，安装了某一个版本比如 1.05，之升级动作是通过检查有否更新的文件——验证文件数字签名（比如MD5摘要信息），但升级后的软件是哪个版本呢？
一个软件的版本实际上是组成该版本的所有特定版本文件的集合。
1的方式可以用Winzip/Winrar等等做一个自解压文件，或者在线升级程序下载新的文件覆盖本地文件，甚至可以用补丁制作工具做成exe，在本地执行以二进制方式修改本地文件等等方式来实现。我见过瑞星工程师在域里就是用一个启动脚本在客户端运行服务器共享目录里的批处理复制文件覆盖本地文件...
2、Hotfix
类似于Windows的hotfix/servicepack这样的方式的补丁，则是一种非线性的升级方式。与方式1类似，但hotfix方式并不是“升级”——Upgrade，更准确地说应该是“补丁”——patch。也就是说，在版本 V1.05 之上有若干补丁，你可以装这些补丁（微软的Service Pack往往包含了前面发布的相关Hotfix和一些其他的工具）中的某一些。
参考“一个软件的版本实际上是组成该版本的所有特定版本文件的集合”，可知这个概念不会影响到当前的“版本”这一概念。
这一点，与1相似。不同的是，技术实现上你可以看到每一个hotfix实际上是一个独立的product installation。
最典型地：每装一个 hotfix，添加删除程序中会多一个条目。如果允许的话（比如hotfix之间没有互相影响），可以单独删除某个hotfix。
3、Transform
从上面看可以知道，Hotfix或者SP并不是将你的软件升级成新版本（或者仅仅升级Build），那么要把V1.05版本升级到2.0怎么做呢？
InstallShield MSI Project/Basic MSI Project 的 patch 实际上就是 Windows Installer 机制中的 trasform。
制作出来的“升级”补丁，也就是“升级包”。
比如在2.0版的安装程序中针对1.05做了一个升级补丁 Update1.05To2.0.msi/Update1.05To2.0.exe，运行之后，你会发现添加删除程序中并没有增加一个新的“产品”项，而原来的 1.05 的项变成了 2.0 的。
这才是真正意义上的升级。
因此，可以把3这种方法看作是
1.05 版本 + 1.05-2.0 版本所需要做出的“所有”改变（不仅仅是文件更新、新增/删除文件，甚至可能有注册表信息、快捷方式甚至数据库配置等等的更改）的集合。假如 1.05 的所有 hotfix 都装了（或者ServicePack），就相当于 2.0 的话，那么你可以理解为 所有 hotfix(sp)加起来就是升级包，呵呵。
InstallShield 提供的补丁制作功能很不错，我每发布一个新版本的客户端，会发布一个新版本的完整安装程序，然后发布一个个针对指定版本的升级包（也可以在一个升级包中支持对多个版本的升级，但文件可能稍大）。
补充说明：
在 InstallShield 有两个功能：
Upgrades
Patch Design
前者主要用于制作全新的完整的安装（升级）包，运行时如果当前计算机上没有旧版本，则执行完整安装。如果有，则升级原有安装。
后者主要制作版本升级补丁，比前者小，更有针对性，比较适合在网络上发布或者用于在线升级。但假如在从一个版本到另外一个版本的升级过程中需要移动某些文件的位置，则一定要用Upgrade方式，而非Patch方式。
另外，help中提到 Patch 方式不能制作 InstallScript MSI Project 的 Major 升级，只能用Upgrade方式。但在实际应用中，我的确用一个 Patch 将客户端软件从 2.5 Build 74 升级到了 3.0 Build 76 版本（2.50.0074 到 3.00.0076）。
题外：有意思，有空仔细看看 Upgrade，说不定前面和朋友讨论的安装时不能“升级”已有的文件的问题就靠它解决了。
关于 InstallShield Projects：
InstallShield 可以创建三种类型的项目（Project）
1、InstallScript Project
2、InstallScript MSI Project
3、Basic MSI Project
前者完全是 InstallShield 自己的功能实现
后两者基于 Windows Installer，InstallScript MSI Project 在 Windows Installer 基础上提供了一些 InstallShield 自己的扩展功能支持。
Basic MSI Project 完全基于 Windows Installer，制作出来的安装程序完全符合W2K相关标准，因此比较适合在 Windows 域中使用。
InstallScript MSI Project 制作出来的安装程序中可以见到 xxx.msi 文件。该 msi 文件离开了 InstallShield 的 engine 无法独立运行。而 Basic MSI Project 的 msi 文件是可以独立运行的（在域里面就知道好处了） :)
InstallShield 做补丁的机制也与 MSI 补丁有区别。
关于版本升级补丁和热修复补丁：
说到做补丁，也有很多不同的方法
1、很多如网络游戏、瑞星等，安装了某一个版本比如 1.05，之升级动作是通过检查有否更新的文件——验证文件数字签名（比如MD5摘要信息），但升级后的软件是哪个版本呢？
一个软件的版本实际上是组成该版本的所有特定版本文件的集合。
1的方式可以用Winzip/Winrar等等做一个自解压文件，或者在线升级程序下载新的文件覆盖本地文件，甚至可以用补丁制作工具做成exe，在本地执行以二进制方式修改本地文件等等方式来实现。我见过瑞星工程师在域里就是用一个启动脚本在客户端运行服务器共享目录里的批处理复制文件覆盖本地文件...
2、Hotfix
类似于Windows的hotfix/servicepack这样的方式的补丁，则是一种非线性的升级方式。与方式1类似，但hotfix方式并不是“升级”——Upgrade，更准确地说应该是“补丁”——patch。也就是说，在版本 V1.05 之上有若干补丁，你可以装这些补丁（微软的Service Pack往往包含了前面发布的相关Hotfix和一些其他的工具）中的某一些。
参考“一个软件的版本实际上是组成该版本的所有特定版本文件的集合”，可知这个概念不会影响到当前的“版本”这一概念。
这一点，与1相似。不同的是，技术实现上你可以看到每一个hotfix实际上是一个独立的product installation。
最典型地：每装一个 hotfix，添加删除程序中会多一个条目。如果允许的话（比如hotfix之间没有互相影响），可以单独删除某个hotfix。
3、Transform
从上面看可以知道，Hotfix或者SP并不是将你的软件升级成新版本（或者仅仅升级Build），那么要把V1.05版本升级到2.0怎么做呢？
InstallShield MSI Project/Basic MSI Project 的 patch 实际上就是 Windows Installer 机制中的 trasform。
制作出来的“升级”补丁，也就是“升级包”。
比如在2.0版的安装程序中针对1.05做了一个升级补丁 Update1.05To2.0.msi/Update1.05To2.0.exe，运行之后，你会发现添加删除程序中并没有增加一个新的“产品”项，而原来的 1.05 的项变成了 2.0 的。
这才是真正意义上的升级。
因此，可以把3这种方法看作是
1.05 版本 + 1.05-2.0 版本所需要做出的“所有”改变（不仅仅是文件更新、新增/删除文件，甚至可能有注册表信息、快捷方式甚至数据库配置等等的更改）的集合。假如 1.05 的所有 hotfix 都装了（或者ServicePack），就相当于 2.0 的话，那么你可以理解为 所有 hotfix(sp)加起来就是升级包，呵呵。
InstallShield 提供的补丁制作功能很不错，我每发布一个新版本的客户端，会发布一个新版本的完整安装程序，然后发布一个个针对指定版本的升级包（也可以在一个升级包中支持对多个版本的升级，但文件可能稍大）。
补充说明：
在 InstallShield 有两个功能：
Upgrades
Patch Design
前者主要用于制作全新的完整的安装（升级）包，运行时如果当前计算机上没有旧版本，则执行完整安装。如果有，则升级原有安装。
后者主要制作版本升级补丁，比前者小，更有针对性，比较适合在网络上发布或者用于在线升级。但假如在从一个版本到另外一个版本的升级过程中需要移动某些文件的位置，则一定要用Upgrade方式，而非Patch方式。
另外，help中提到 Patch 方式不能制作 InstallScript MSI Project 的 Major 升级，只能用Upgrade方式。但在实际应用中，我的确用一个 Patch 将客户端软件从 2.5 Build 74 升级到了 3.0 Build 76 版本（2.50.0074 到 3.00.0076）。
题外：有意思，有空仔细看看 Upgrade，说不定前面和朋友讨论的安装时不能“升级”已有的文件的问题就靠它解决了。
#8
看来是我用的IS版本低了！
谢谢piggybank(吞硬币的小猪) 及eric_alex(ericwang)!
谢谢piggybank(吞硬币的小猪) 及eric_alex(ericwang)!
#1
你看换个思路行不行，把你要升级的文件列表写到一个文件里，安装的时候根据这个文件里的内容去复制文件。
不过呢，这个安装包应该不叫做升级安装包了，完全是一个独立的安装包了吧，升级安装包的话，还是应该用installshield提供的patch、upgrade的做法去实现。
不过呢，这个安装包应该不叫做升级安装包了，完全是一个独立的安装包了吧，升级安装包的话，还是应该用installshield提供的patch、upgrade的做法去实现。
#2
请问eric_alex(ericwang) :
installshield提供的patch、upgrade怎么用呢，可否提个醒？
installshield提供的patch、upgrade怎么用呢，可否提个醒？
#3
>不过呢，这个安装包应该不叫做升级安装包了，完全是一个独立的安装包了吧，升级安装包的话，还是应该用installshield提供的patch、upgrade的做法去实现。
是啊，你这是一个新的安装包了，呵呵
从来没用过瑞星，最近在客户的专网里见它们在 W2K Domain 里做瑞星客户端升级，居然是在启动脚本里从服务器的share folder里copy文件...
汗..
是啊，你这是一个新的安装包了，呵呵
从来没用过瑞星，最近在客户的专网里见它们在 W2K Domain 里做瑞星客户端升级，居然是在启动脚本里从服务器的share folder里copy文件...
汗..
#4
>installshield提供的patch、upgrade怎么用呢，可否提个醒？
从 InstallShield Developer 8.02 到 DevStudio 9 和现在的 X 都能很好地制作补丁。
要提醒的是（我的教训），如果可能用到 Windows 域里，最好用 MSI Project，而非 InstallScript MSI Project。因为一般在域里的权限限制在客户端执行 exe 安装，但 msi 的好处在于还可以支持 SMS 并可以从服务器上远程分发/指派。
呵呵，我做了个自动升级检测模块，现在在考虑加入各种补丁方式实现的支持，做成一个通用的 Update Service。
从 InstallShield Developer 8.02 到 DevStudio 9 和现在的 X 都能很好地制作补丁。
要提醒的是（我的教训），如果可能用到 Windows 域里，最好用 MSI Project，而非 InstallScript MSI Project。因为一般在域里的权限限制在客户端执行 exe 安装，但 msi 的好处在于还可以支持 SMS 并可以从服务器上远程分发/指派。
呵呵，我做了个自动升级检测模块，现在在考虑加入各种补丁方式实现的支持，做成一个通用的 Update Service。
#5
请问楼上二位，patch、upgrade是install shield professional 中提供的工具组件吗？我还不知道如何找到这些工具。InstallScript MSI Project是独立的程序吧？
#6
能者请继续指教！
#7
不是独立的工具，是 InstallShield 7.0 Pro开始加入的一个功能，ISDeveloper 8.0/ ISDevStudio 9.0 比较稳定可用，X 我还没用过 :)
关于 InstallShield Projects：
InstallShield 可以创建三种类型的项目（Project）
1、InstallScript Project
2、InstallScript MSI Project
3、Basic MSI Project
前者完全是 InstallShield 自己的功能实现
后两者基于 Windows Installer，InstallScript MSI Project 在 Windows Installer 基础上提供了一些 InstallShield 自己的扩展功能支持。
Basic MSI Project 完全基于 Windows Installer，制作出来的安装程序完全符合W2K相关标准，因此比较适合在 Windows 域中使用。
InstallScript MSI Project 制作出来的安装程序中可以见到 xxx.msi 文件。该 msi 文件离开了 InstallShield 的 engine 无法独立运行。而 Basic MSI Project 的 msi 文件是可以独立运行的（在域里面就知道好处了） :)
InstallShield 做补丁的机制也与 MSI 补丁有区别。
关于版本升级补丁和热修复补丁：
说到做补丁，也有很多不同的方法
1、很多如网络游戏、瑞星等，安装了某一个版本比如 1.05，之升级动作是通过检查有否更新的文件——验证文件数字签名（比如MD5摘要信息），但升级后的软件是哪个版本呢？
一个软件的版本实际上是组成该版本的所有特定版本文件的集合。
1的方式可以用Winzip/Winrar等等做一个自解压文件，或者在线升级程序下载新的文件覆盖本地文件，甚至可以用补丁制作工具做成exe，在本地执行以二进制方式修改本地文件等等方式来实现。我见过瑞星工程师在域里就是用一个启动脚本在客户端运行服务器共享目录里的批处理复制文件覆盖本地文件...
2、Hotfix
类似于Windows的hotfix/servicepack这样的方式的补丁，则是一种非线性的升级方式。与方式1类似，但hotfix方式并不是“升级”——Upgrade，更准确地说应该是“补丁”——patch。也就是说，在版本 V1.05 之上有若干补丁，你可以装这些补丁（微软的Service Pack往往包含了前面发布的相关Hotfix和一些其他的工具）中的某一些。
参考“一个软件的版本实际上是组成该版本的所有特定版本文件的集合”，可知这个概念不会影响到当前的“版本”这一概念。
这一点，与1相似。不同的是，技术实现上你可以看到每一个hotfix实际上是一个独立的product installation。
最典型地：每装一个 hotfix，添加删除程序中会多一个条目。如果允许的话（比如hotfix之间没有互相影响），可以单独删除某个hotfix。
3、Transform
从上面看可以知道，Hotfix或者SP并不是将你的软件升级成新版本（或者仅仅升级Build），那么要把V1.05版本升级到2.0怎么做呢？
InstallShield MSI Project/Basic MSI Project 的 patch 实际上就是 Windows Installer 机制中的 trasform。
制作出来的“升级”补丁，也就是“升级包”。
比如在2.0版的安装程序中针对1.05做了一个升级补丁 Update1.05To2.0.msi/Update1.05To2.0.exe，运行之后，你会发现添加删除程序中并没有增加一个新的“产品”项，而原来的 1.05 的项变成了 2.0 的。
这才是真正意义上的升级。
因此，可以把3这种方法看作是
1.05 版本 + 1.05-2.0 版本所需要做出的“所有”改变（不仅仅是文件更新、新增/删除文件，甚至可能有注册表信息、快捷方式甚至数据库配置等等的更改）的集合。假如 1.05 的所有 hotfix 都装了（或者ServicePack），就相当于 2.0 的话，那么你可以理解为 所有 hotfix(sp)加起来就是升级包，呵呵。
InstallShield 提供的补丁制作功能很不错，我每发布一个新版本的客户端，会发布一个新版本的完整安装程序，然后发布一个个针对指定版本的升级包（也可以在一个升级包中支持对多个版本的升级，但文件可能稍大）。
补充说明：
在 InstallShield 有两个功能：
Upgrades
Patch Design
前者主要用于制作全新的完整的安装（升级）包，运行时如果当前计算机上没有旧版本，则执行完整安装。如果有，则升级原有安装。
后者主要制作版本升级补丁，比前者小，更有针对性，比较适合在网络上发布或者用于在线升级。但假如在从一个版本到另外一个版本的升级过程中需要移动某些文件的位置，则一定要用Upgrade方式，而非Patch方式。
另外，help中提到 Patch 方式不能制作 InstallScript MSI Project 的 Major 升级，只能用Upgrade方式。但在实际应用中，我的确用一个 Patch 将客户端软件从 2.5 Build 74 升级到了 3.0 Build 76 版本（2.50.0074 到 3.00.0076）。
题外：有意思，有空仔细看看 Upgrade，说不定前面和朋友讨论的安装时不能“升级”已有的文件的问题就靠它解决了。
关于 InstallShield Projects：
InstallShield 可以创建三种类型的项目（Project）
1、InstallScript Project
2、InstallScript MSI Project
3、Basic MSI Project
前者完全是 InstallShield 自己的功能实现
后两者基于 Windows Installer，InstallScript MSI Project 在 Windows Installer 基础上提供了一些 InstallShield 自己的扩展功能支持。
Basic MSI Project 完全基于 Windows Installer，制作出来的安装程序完全符合W2K相关标准，因此比较适合在 Windows 域中使用。
InstallScript MSI Project 制作出来的安装程序中可以见到 xxx.msi 文件。该 msi 文件离开了 InstallShield 的 engine 无法独立运行。而 Basic MSI Project 的 msi 文件是可以独立运行的（在域里面就知道好处了） :)
InstallShield 做补丁的机制也与 MSI 补丁有区别。
关于版本升级补丁和热修复补丁：
说到做补丁，也有很多不同的方法
1、很多如网络游戏、瑞星等，安装了某一个版本比如 1.05，之升级动作是通过检查有否更新的文件——验证文件数字签名（比如MD5摘要信息），但升级后的软件是哪个版本呢？
一个软件的版本实际上是组成该版本的所有特定版本文件的集合。
1的方式可以用Winzip/Winrar等等做一个自解压文件，或者在线升级程序下载新的文件覆盖本地文件，甚至可以用补丁制作工具做成exe，在本地执行以二进制方式修改本地文件等等方式来实现。我见过瑞星工程师在域里就是用一个启动脚本在客户端运行服务器共享目录里的批处理复制文件覆盖本地文件...
2、Hotfix
类似于Windows的hotfix/servicepack这样的方式的补丁，则是一种非线性的升级方式。与方式1类似，但hotfix方式并不是“升级”——Upgrade，更准确地说应该是“补丁”——patch。也就是说，在版本 V1.05 之上有若干补丁，你可以装这些补丁（微软的Service Pack往往包含了前面发布的相关Hotfix和一些其他的工具）中的某一些。
参考“一个软件的版本实际上是组成该版本的所有特定版本文件的集合”，可知这个概念不会影响到当前的“版本”这一概念。
这一点，与1相似。不同的是，技术实现上你可以看到每一个hotfix实际上是一个独立的product installation。
最典型地：每装一个 hotfix，添加删除程序中会多一个条目。如果允许的话（比如hotfix之间没有互相影响），可以单独删除某个hotfix。
3、Transform
从上面看可以知道，Hotfix或者SP并不是将你的软件升级成新版本（或者仅仅升级Build），那么要把V1.05版本升级到2.0怎么做呢？
InstallShield MSI Project/Basic MSI Project 的 patch 实际上就是 Windows Installer 机制中的 trasform。
制作出来的“升级”补丁，也就是“升级包”。
比如在2.0版的安装程序中针对1.05做了一个升级补丁 Update1.05To2.0.msi/Update1.05To2.0.exe，运行之后，你会发现添加删除程序中并没有增加一个新的“产品”项，而原来的 1.05 的项变成了 2.0 的。
这才是真正意义上的升级。
因此，可以把3这种方法看作是
1.05 版本 + 1.05-2.0 版本所需要做出的“所有”改变（不仅仅是文件更新、新增/删除文件，甚至可能有注册表信息、快捷方式甚至数据库配置等等的更改）的集合。假如 1.05 的所有 hotfix 都装了（或者ServicePack），就相当于 2.0 的话，那么你可以理解为 所有 hotfix(sp)加起来就是升级包，呵呵。
InstallShield 提供的补丁制作功能很不错，我每发布一个新版本的客户端，会发布一个新版本的完整安装程序，然后发布一个个针对指定版本的升级包（也可以在一个升级包中支持对多个版本的升级，但文件可能稍大）。
补充说明：
在 InstallShield 有两个功能：
Upgrades
Patch Design
前者主要用于制作全新的完整的安装（升级）包，运行时如果当前计算机上没有旧版本，则执行完整安装。如果有，则升级原有安装。
后者主要制作版本升级补丁，比前者小，更有针对性，比较适合在网络上发布或者用于在线升级。但假如在从一个版本到另外一个版本的升级过程中需要移动某些文件的位置，则一定要用Upgrade方式，而非Patch方式。
另外，help中提到 Patch 方式不能制作 InstallScript MSI Project 的 Major 升级，只能用Upgrade方式。但在实际应用中，我的确用一个 Patch 将客户端软件从 2.5 Build 74 升级到了 3.0 Build 76 版本（2.50.0074 到 3.00.0076）。
题外：有意思，有空仔细看看 Upgrade，说不定前面和朋友讨论的安装时不能“升级”已有的文件的问题就靠它解决了。
#8
看来是我用的IS版本低了！
谢谢piggybank(吞硬币的小猪) 及eric_alex(ericwang)!
谢谢piggybank(吞硬币的小猪) 及eric_alex(ericwang)!