About datamine

datamine · ‎Sep 20, 2023

Thanks, that has stopped the message popping up.

datamine · ‎Sep 19, 2023

I'm seeing this error using InstallShield 2014, and removing the CERxxxx.tmp doesn't fix it. I'm not even using FlexNet?

datamine · ‎Jun 19, 2023

Hi We are trying to track down the InstallShield licenses that various members of our organisation are using - visiting the Product and Licensing Center shows some licenses that are past their shown "expiration date", but are still in activate use. Is there a way of finding exactly which of these licenses have actually expired, or even been cancelled (I know that we had a cleanup of licenses a few years ago)? TIA Ian Johnson.

datamine · ‎Mar 24, 2016

Just a guess here also, would it not be in "Releases" under "Prepare for Release"?

datamine · ‎Mar 24, 2016

We've come across this problem on numerous occasions in the past, I finally found what I believe to be the answer here: http://www.laurierhodes.info/?q=node/46 In a nutshell, the problem is that Windows Installer evaluates the components *before* the previous version is uninstalled, meaning that components may not be marked for inclusion because they are older/have not changed. The uninstall then removes these components, and when the install stage goes through those components are not marked to be installed. According to that article, Windows Installer expects that the RemoveExistingProducts custom action is performed at the end of the installation as a kind of "cleanup" operation, not at the start as InstallShield traditionally places it. If it is placed at the beginning then the ref counting mechanism does not work, thus components can go missing. We are in the process of moving RemoveExistingProducts to the end of the Installation/Execute sequence for all our products as this appears to be much more reliable. Hope this helps.

datamine · ‎Oct 01, 2014

It turns out this was a red herring, it works fine when the entries are in Wow6432Node after all, there were just a few missing.

datamine · ‎Sep 30, 2014

Thanks for the reply 🙂 I tried a custom InstallScript action which sets REGDB_OPTIONS in this way, just before WriteRegistryValues (which I assume will write the contents of the Registry table) but the result is the same unfortunately. I could probably achieve the desired effect entirely in InstallScript but that defeats the object (and flexibility) of merging a .reg file at build time, there are too many entries to add in script.

datamine · ‎Sep 30, 2014

Hi I have a basic MSI project in which we include a .reg file to set up COM entries for a particular 32-bit component. Since the advent of Windows 7, registry reflection has been disabled so these entries always appear under HKEY_CLASSES_ROOT\Wow6432Node and not under HKEY_CLASSES_ROOT as they did before. However, certain apps do not recognise the component as registered unless they are under HKEY_CLASSES_ROOT, which is where they appear if the component is registered manually. I have tried (and so far failed) to force these entries to be set under HKEY_CLASSES_ROOT by default. I've tried setting "Disable Registry Reflection", some InstallScript to set REGDB_OPTIONS but neither of these make any difference, and I really don't want to have to resort to making the component self-register. Does anyone know of a method I can use to force these entries into the right place?

datamine · ‎Sep 11, 2013

Thanks for the reply 🙂 We do need the ref counts because these are shared components, and on a clean install they work fine (i.e. 1). However, we have had issues in the past with major upgrades because for some inexplicable reason Windows Installer evaluates what needs doing to components *before* it uninstalls the old products so we've sometimes had odd components not reinstalled after the upgrade etc. Thus it appears this evaluation was causing the dynamic files to be reinstalled and the new files on top of that, causing a ref count of 2. The solution I have found (for anyone else who may have this problem) is this; it's not very elegant, and it's still a little unclear to me as to why it actually works: After the SetupProgress custom action in Installation/User Interface, I have an InstallScript custom action which simply calls: MsiSetFeatureState(hMSI, " ", INSTALLSTATE_ABSENT); Then just before the ProcessComponents custom action in Installation/Execute (and after RemoveExistingProducts) I call another InstallScript action which does: MsiSetFeatureState(hMSI, " This appears to fool Windows Installer into not pre-evaluating the components within this feature, and they are installed correctly with ref counts of 1.

datamine · ‎Sep 10, 2013

We've recently removed a component which installed files from a dynamic folder to install each file as an individual component. We've set it to a major upgrade so that it completely uninstalls the old product and reinstalls the new, but we're finding that when the new components are reinstalled all the file have a ref count of 2, as if something has "remembered" the old files and assumes they were already installed. This obviously isn't a problem until the user uninstalls, at which point all these files are left behind. Manually uninstalling the old and then installing the new operates correctly. Has anyone else come across this problem, and if so is there a solution please?

datamine · ‎Jul 04, 2013

I've just downloaded and tried to use this prerequisite and it's not working for me either. The Helper.exe seems to be kicking off Windows Modules Installer but after a while all goes quiet and the helper never exits. Does anyone know if there have been any updates to this?

datamine · ‎Jul 31, 2012

As part of a change in our build processes we have just upgraded to InstallShield 2012 Spring. As part of this change it is no longer ideal to add a Merge Module path to every installation of InstallShield so that it picks up any locally-built Merge Modules - is there any way to specify Merge Modules via a path on a project-by-project basis? TIA Ian Johnson.

datamine · ‎Apr 18, 2012

I guess this forum isn't as active as it used to be then. Just as an FYI, the only way I could find to get around this was to pick the value up via the RegLocator table, and all the jumping through hoops that entails.

datamine · ‎Apr 16, 2012

I am trying to read a value from the registry in InstallScript using RegDBGetKeyValueEx where the name of the value contains curly brackets {}, however no matter how I specify this name no value is returned. I had originally assumed this was being altered in some way at build time, however I am now beginning to suspect that it is happening at runtime as I have tried creating a string table entry and reading it using LoadStringFrom StringTable and passing the result into the function, but this still returns nothing. Can anyone tell me a syntax I can use to read these values from the registry? TIA

datamine · ‎Nov 26, 2010

In time-honoured fashion, I have now discovered that the cause of this is some script that we run to force certain features to install, but should not be run in Maintenance mode. As you were!

Online Status	Offline
Date Last Visited	‎Sep 20, 2023 07:08 AM

Re: Certificate error

Re: Certificate error

Product and Licensing Center expiration dates.

Re: How to rename Setup.exe?

Re: "Completely uninstall old setup before installing new setup", incorrect behaviour

Re: Interface registry entries not reflected

Re: Interface registry entries not reflected

Interface registry entries not reflected

Re: Problem with major upgrade where dynamic folders have been changed to components

Problem with major upgrade where dynamic folders have been changed to components

Re: Enable .Net 3.51 in Windows 8, Windows 2008/2012 Server

Merge Module locations

Re: RegDBGetKeyValueEx - special characters in szName

RegDBGetKeyValueEx - special characters in szName

Re: Uninstall from original installer does not remove everything

Re: Certificate error

Re: Certificate error

Product and Licensing Center expiration dates.

Re: How to rename Setup.exe?

Re: "Completely uninstall old setup before installing new setup", incorrect behaviour

Re: Interface registry entries not reflected

Re: Interface registry entries not reflected

Interface registry entries not reflected

Re: Problem with major upgrade where dynamic folders have been changed to components

Problem with major upgrade where dynamic folders have been changed to components