Installshield 2009 多个序列号
我一直在使用 Installshield 2009 和 C# 创建一个安装项目，在安装之前验证序列密钥（用 .NET 编写的算法）。效果很好。
但是我有一个产品的多个版本。目前我为每个版本使用单独的安装项目。然而，许多文件是相同的，只有包含或不包含文件的微小变化。如果我可以有一个部署项目，根据检测到的有效序列密钥来安装某些文件，我会很高兴。
基本上我想知道 Installshield 是否可以实现这种事情。
提前致谢
I have been playing around with Installshield 2009 and C# to create a setup project that validates a serial key (the algorithm written in .NET) before installation. It works great.
However I have several versions of a product. At the moment I use separate setup projects for each version. However many of the files are the same, with only small variations in which files are included or not. I would love it if I could have a single deployment project that installs certain files depending on which valid serial key is detected.
Basically I'm wondering if this sort of thing is possible with Installshield.
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Windows Installer 不太适合您描述的情况，至少除非您花时间通过某种许可技术来防止使用不正确安装的文件。您可以让串行验证 dll 还设置一个属性，该属性可以影响各种功能或组件的条件，但是转换可以轻松回避这一点。除非您已经（或可以）花时间来实施许可证验证，否则最好的选择是维护单独的版本（每个不同的允许文件集一个）。但是，您也许可以将它们合并到一个项目中。
根据不同版本之间的具体差异，我认为有两种互补的方法可以让您获得单独的 SKU。第一个最容易在每个版本的基础上指定，您可以从命令行选择要构建的版本。第二个与版本无关，可以手动更新，也可以在命令行构建中覆盖。
释放标志
您可以将项目组分成额外的功能（可能是隐藏的，这样它们就不会混乱功能选择对话框），然后在每个版本上使用版本标志来在构建时包含或排除这些文件。如果您要更改内容文件，但继续在不同的 SKU 中使用相同的自定义操作 DLL，这可能效果最好。
路径变量
可以使用路径变量指定自定义操作 DLL 的路径，然后您可以使用该路径变量覆盖文件的源位置。确保相应的条目（可能在文件或二进制表中）在尖括号中使用自己的变量，然后您也可以在构建时单独交换它。如果您需要更改自定义操作 DLL，这很有意义，并且可以与发布标志一起使用。
Windows Installer isn't well suited to the scenario you describe, at least unless you take the time to prevent the use of improperly installed files with some sort of licensing technology. You could have your serial validation dll also set a property that various features or components condition off of, however a transform can easily sidestep this. Unless you've taken (or can take) the time to implement license verification, your best bet is to maintain separate builds (one per different set of allowed files). However you may be able to merge these into a single project.
Depending on exactly what differs between builds, I think there are two complementary approaches that get you your separate SKUs. The first is most easily specified on a per-release basis, and you can select which release to build e.g. from the command line. The second is irrespective of release, and can either be updated manually or can be overridden in a command line build.
Release Flags
You can separate groups of items into extra features (perhaps hidden so they don't clutter the feature selection dialog), and then use release flags on a per-release to include or exclude these files at build time. This would probably work best if you are changing out content files, but continue to use the same custom action DLL across separate SKUs.
Path Variables
The path to your custom action DLL can be specified with a path variable that you can then use to override the source location of the file. Make sure the corresponding entry (likely either in the File or Binary table) uses its own variable in the angle brackets, and then you can swap it out individually at build time as well. This makes sense if you need to change your custom action DLL, and can be used alongside Release Flags.
您可以在运行时添加和删除功能。这可以通过 (a) 安装程序属性或 (b) 安装屏蔽脚本来完成。
首先，您将所有版本的所有功能添加到项目中。您将确保它们没有被选择安装。然后您可以在运行时使用方法 a 或 b 来选择一个。
安装程序属性 (a) 可以通过多种方式设置。命令行切换到安装程序、操作系统版本、存在的某些注册表项，或通过 DLL 中的自定义逻辑。并且可以根据安装程序属性是否为特定值来包含/排除功能。
对于(b)，脚本可以访问“特征树”并且可以选择&使用 FeatureSelectItem() 等根据自定义逻辑取消选择它们
You can add and remove features at run-time. This can be accomplished with (a) installer properties or (b) in install shield scripts.
First you would add all the features for all the versions to the project. You would ensure they are not selected to be installed. Then you would use either method a or b to select one while running.
Installer properties (a) can be set in various ways. Command line switches to the installer, OS versions, certain reg keys being present, or via custom logic in a DLL. And features can be included/excluded based on an installer property being a certain value.
As for (b), the script has access to the "feature tree" and can select & unselect them based on custom logic using FeatureSelectItem(), etc