About Matthias1967

Matthias1967 · ‎Apr 26, 2016

@Debbie: The original question was about tables, not directories. Thank you Michael for pointing out.

Matthias1967 · ‎Mar 27, 2012

You should check the property VersionNT64.

Matthias1967 · ‎Mar 16, 2012

Hello Tim, you state that "Chaining does not play nice with the 3010 return". I thin that is understatement. Chaining considers everything differnt from 1601 an error and rolls back the chain without even writign the reason into the log file. I think this is a rather nasty bug... Is any fix in sight? Best regards Matthias

Matthias1967 · ‎Mar 16, 2012

Hello sarfuis, I am getting the same issue with IS2010 on several OSs. BTW, if I just reboot the machine (or kill msiexec.exe), everything is there! I am heavily searching for solutions to this issue, but have not yet found any answers. What is more, the chainer does not write anything to the log file, so I do not get any clues from there either. I think this is a bug (in the ISChainer or in Windows Installer?) that should be fixed soon... Best regards Matthias

Matthias1967 · ‎Mar 16, 2012

Hello enanrum, thank you very much for that idea! I have implemented a different solution, which works so far - at least for my purposes: I schedule a CA "KeepDependencies" after InstalllValidate. I keep track of those suspicious dependencies myself - either hard-coded in the CA or by a custom table. The CA checks whether the dependency is to be removed (I call MsiGetComponentState on the Dependency and evaluate nvActionStateDep = INSTALLSTATE_ABSENT) - I do not use condition on the CA here because there may be more than one entry in the dependencies list. If so, I check the ComponentState of the parent component. If this is to be kept (or installed) (nvInstallStateParent != INSTALLSTATE_ABSENT && nvActionStateParent != INSTALLSTATE_ABSENT), I set the action state of the dependency to local: MsiSetComponentState(hMSI,svDependency,INSTALLSTATE_LOCAL); The intention of my post was rather to ask whether Windows Installer has some "built-in" solution for this issue - from your reply, I think there is really none... Best regards Matthias

Matthias1967 · ‎Mar 12, 2012

Hello, I am writing MSI setups for several applications that share some components. One of these components got an additional DLL dependency in the current version. Of course, I added that DLL as a new component. Now consider the following scenario: User has two applications of ours installed, one of them using the newest version of the shared component, one of them using an older version of the shared component. This results in the shared component being installed in the newest version, and the adiditional DLL being present. Now the user uninstalls the application that has brought the newest version of the shared component. As a result, the shared component remains on the computer (since it is still referenced by the other application) in its newest version. But the additional component is gone, because the application just uninstalled was its only reference. So this shared component cannot be used any more! As of now, I see basically two solutions, both of which look ugly to me: 1) Never add a dependency to a shared component - I do not think that app developers will ever comply with this 2) make that "new" DLL a permanent component - this means it will remain there even after uninstall, even if no more needed at all Any other ideas? Best regards Matthias

Matthias1967 · ‎Nov 15, 2011

Hej Branedal, no, I have not found any more info yet, as with some other issues concerning chaining. So I still have positioned RemoveExistingProducts before InstallInitialize, which is ugly, but seems to be necessary for the install to work at all.:mad: Best regards Matthias

Matthias1967 · ‎Apr 13, 2011

Windows Installer runs in two different processes: a client process running the User Interface sequence and a server process running the Execute sequence. When Windows Installer switches from the client to the server process, UAC asks for permission. By default, the "Install" button on the ReadyToInstall dialog should display the UAC shield icon. If you want elevated privileges from the beginning (this may be needed for custom actions running in user context, even in the Execute sequence...), you have to set these privileges in setup.exe. In the Releases view of InstallShield, select a release, go to the setup.exe tab, set "Required Execution Level" to "Administrator". Best regards, Matthias

Matthias1967 · ‎Mar 19, 2011

To expand this bug report a bit: Even the attributes dt:dt="bin.base64" md5="d41d8cd98f00b204e9800998ecf8427e" in the XML "table cell" for the "Data" column of the Binary table do not seem to be in order here. They are exactly the same regardless which file I add, so it has nothing ot do with an MD5 hash of the actual file, and entries that InstallShield automatically adds to the Binary table do not have these attributes. If I delete not only the line breaks, but also these attributes, these files are perfectly streamed into the Binary table. So adding a file to the Binary table in the Direct Editor corrupts the project file, if saved as XML. I think this is a clear bug; however I have not found any document in the knowledge base concerning this issue yet. Regards Matthias

Matthias1967 · ‎Mar 18, 2011

In order for the prerequisite to be visible in the list, it must be located in the prerequisites folder, which is hard-selected by InstallShield: InstallShield Program Files Folder\SetupPrerequisites Unlike Merge Modules, I do not know a way to show Prerequisites located in other folders - I consider this to be an InstallShield bug. Best regards Matthias

Matthias1967 · ‎Mar 15, 2011

Hello Christian, the path variables are resolved and "gone" as soon as the install package is built. Moreover, they do not refer to the installation medium (CD or network or whatever), but to the very source on your developer's machine. I do not think that this file structure is useful information for the installation process running on the user's machine. If you do want the setup to behave differently depending on the source paths you have built from, you should: 1) Reconsider your design. 2) include this information in a location (separate file, ini entry, ...) that is accessible at installation time. Best regards, Matthias

Matthias1967 · ‎Mar 15, 2011

Probably you are right that the ultimate cause of the error is in one of the installations taking part in the chain, possibly including the "master". However, there are cases when it would be very helpful to get at least a hint why a chained installation does not start (there is just no log entry from the chained package). The other day, I have posted such an example in that thread where I don't get any clue why a chained package does not start if the "master" is a major upgrade with RemoveExistingProducts scheduled just before InstallFinalize. Best regards Matthias

Matthias1967 · ‎Mar 07, 2011

Hi there, does ISChain.exe issue any error messages? If so, is there a chance for the user to read those messages? There are cases where the very act of chaining fails (the main setup runs till the end, then at the point where the chained package should be started, the setup is rolled back instead). This currently leads to a "silent roll-back" without any descriptive error message. 😞 Best regards Matthias

Matthias1967 · ‎Mar 04, 2011

Is there also a dependency on the positioning of RemoveExistingProducts? I recently found that a Major Upgrade for the "Main" package works only if RemoveExistingProducts is scheduled before InstallInitialize. Is this a known issue, or may something have gone wrong from my side? Regards Matthias

Matthias1967 · ‎Mar 04, 2011

Now I have tried the major upgrade with several positions of RemoveExistingProducts. If RemoveExistingProducts is positioned before InstallInitialize, the major upgrade works. For the other three possible positions (immediately after InstallInitialize, after InstallExecute, or after InstallFinalize), major upgrade silently starts a rollback at the end of the Execute sequence (at the moment when the chained setup should be started). I have set the UI level of the chained package to /qr, although with RemoveExistingProducts after InstallInitialize, the rollback also occurs with /qb (I have not tried the other combinations). The install condition for the chained package is set to REMOVE <> "ALL" AND NOT ISCHAINER Thje uninstall condition for the chained package is set to REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE Any ideas would be appreciated. Best regards Matthias

Online Status	Offline
Date Last Visited	‎Mar 06, 2020 08:15 AM

Tables, not directories

Re: how to install different files according to the operating system

Re: Chained install performing rollback - returning 3010.

Re: Installer hanging after Installation. Chain MSIs.

Re: "dependent" component?

"dependent" component?

Nothing new yet

Re: Requesting elevated privileges from msi

Bug - XML project file gets corrupted when adding a file to binary table

Re: How to update or add a prerequisite

Re: Is there a way to use Path Variables in InstallScript?

Re: ISChain.exe errors?

ISChain.exe errors?

Re: Question About Upgrading Chained Installers

investigation results