Well, if you're looking for a band-aid solution that will let you migrate ISPROJ files at your convenience, assuming you're migrating all your projects to IS2008, you could always copy the IS2008 MSBuild folder to the IS12 position... I like to think of the targets file as the one InstallShield owns, and the ISPROJ file as the one the customer owns, but here is clearly a place where that breaks down a little. Also since I don't get to use MSBuild half as much as you, I haven't internalized the patterns you can really use. I wonder if moving forward we'd be better off doing the import using a custom MSBuild property, which we could assert ownership of and update, and if you wanted to override that you could just replace its use in the import element. It'd still be a chicken and egg for existing projects, but at least future updates could become simpler. ... View more

The updates you reference are all add-ons for InstallScript projects, not InstallScript MSI, so they will not help here. I don't believe we have full support for uninstallable patches in InstallScript MSI projects at this point. Perhaps it's time to start voting for this at http://www.installshield.com/feedback/. ... View more

I'll echo Chris here in saying that I don't think there are any earth-shattering changes which will cause you to have to fundamentally relearn how to use InstallShield. Instead there are a lot of tweaks and improvements (mostly small, some larger) which we hope will only improve your workflow when using it. ... View more

Agreed; the warnings are a matter of unsynchronization between Microsoft's recommendations and the actual implementation of their ICEs. The error is somewhat worrisome. Could you post the full contents of that row of the registry table, especially the Value column? You may have to open your build MSI in direct-edit mode in order to find it. ... View more

There's a bit of a tradeoff to using it, but here's a potential workaround you could use. \Support\0409\Settings.xml has a section with a lot of elements. You could add one with Name="IS_LAUNCH_MY_PROGRAM_PLEASE" and Description="Whatever you like", and I believe it should automatically use that description during build. The tradeoff is if you use Hidden="Y" like all the rest do, it will not be displayed unless you choose to display all CAs, but if you use Hidden="N" it will necessarily do the help correctly. More importantly you will have to update settings.xml on all your build machines. (Personally I don't find ISICE10 to be all that useful, so I'd lean towards disabling it in Tools/Options, but that's your choice to make.) ... View more

Thanks! Have you already switched over to using a .pfx certificate, and have you had any problems doing so, or figuring out how to do so? ... View more

Hmm. On one hand I like the idea of that 'latest' entry, which would be really easy for you to set up yourself by copying (or renaming) the MSBuild subfolder yourself, and optionally editing the ISProj template \Support\0409\msbuild.xml. However if you had done this, and then we implemented upgrade tweaks to the ISProj template, I don't know how we could detect and avoid overwriting your pattern. I don't want to build in knowledge of all previous "legitimate" targets file paths in the upgrader, which means the best thing we could do is copy the value in the current template into the upgrading ISProj... Alternately we could theoretically ask at upgrade, but I'd hate to set precedent which would eventually make upgrading a project more painful than clicking Next Next Next on the release wizard. 🙂 ... View more

It would probably make sense to do so, but there are definitely some small hurdles to overcome, such as ensuring exactly the correct element was modified. It's been like this, requiring manual reconfiguration, since IS11.5 and I'm not aware of much feedback on this yet. Are you likely to modify an ISPROJ file such that /msbuild:Project/msbuild:Import@Project could refer to an import we should leave alone, or does that sound safe? Just to clarify the scenarios I think we can handle, I don't see how we could resolve the first build error you describe. Until you upgrade the project, the first step sounds equivalent to uninstalling the previous SAB, and then expecting some other arbitrary install to satisfy that loss. After upgrading the project, it's just the misaligned Import causing problems. ... View more

ricko2001, yes that is part of the enhanced signature support, but only applies if you are using .pfx certificate files. Our build still uses signcode (with identical password dialog problems) if you use .spc+.pvk files. ... View more

Alright, I've filed this as a bug to be investigated for a fix in a future release; I can't guarantee any timeframe at this point, or whether we'll be able to patch existing versions. You can track this for more information via the number: IOC-000045059. I reproduced this behavior on InstallShield 11.5; what version are you using? ... View more

I found a little more information that might be useful. We use the ServerXMLHTTP object for this query, and apparently it sometimes has some trouble with proxies. This is documented with a potential fix on Microsoft KB article 289481 (http://support.microsoft.com/kb/289481/EN-US/). Let me know if this is useful so we can get a pointer up in our own knowledge base. ... View more

Alright. I'll try to track down whether our license acquiring transaction is proxy-enabled. In the meantime it may be good to confirm that your proxy does allow HTTPS once properly authenticated. You should be able to do this by opening Internet Explorer and going to some normal web site (authenticating), and then visiting a secure website such as Google's secure sign-in. If you cannot load a secure page in Internet Explorer, we're not going to be able to acquire a license via the secure channel. If you can, we just have to make sure we're doing everything right on our side. ... View more

Hmm, I think I misunderstood where the symptom was. There are two times in question and I'm only familiar with one of them. The first is inside the InstallShield IDE when you wish to acquire a license with which to wrap your program for activation; the second is when someone (generally an end-user) activates a wrapped program. My understanding was that the first - acquiring the license - works through proxies correctly. However I'm not familiar with it and will see if I can turn up any information. I've recently worked with the second - activating an instance through a proxy - and have an updated file we can let you test for the activation step. Could you clarify which of the two steps is blocking you right now? I originally answered for the second, but now I think you're at the first. ... View more

The activation process uses port 443 (HTTPS) for activation. Does your proxy allow connections to the internet but require authentication with the proxy first (does IE prompt you for a password?), or do you effectively not have internet access from the PC in question? ... View more

Hi Neal, Are you talking about the behavior mentioned in this KB article with hotfix? http://support.installshield.com/kb/view.asp?articleid=Q111288 If so it looks like it's been available for a little while already. If not, I'd like to make sure we're aware of the difficulties you're encountering. ... View more