Dec 16, 2019
08:18 AM
(This works in projects that use MSI as the installation engine, I don't know enough about pure Installscript projects to help you there) Honestly, I find the prequisite Installer too complicated to use it for installing .NET packages and I kept running in the same problems. It also doesn't make sense to me to install additional packages before your Setup (except when your Custom Actions need .NET themselves). I rather run the required package AFTER I'm sure my own installation had run successfully. This is what I do: Get the online or offline .NET Installer you need from https://docs.microsoft.com/en-us/dotnet/framework/deployment/deployment-guide-for-developers#redistributable-packages and store it in a persistent location Add a System Search for the Registry Key like https://docs.microsoft.com/en-us/dotnet/framework/deployment/deployment-guide-for-developers#detecting-the-net-framework and save the result in a Property, eg PROP_DOTNET_INSTALLED_VERSION. Also make note of the DWORD Version of .Net Framework you require (In your case, 4.7.2 -> 461808) Add a new Custom Action EXE->Stored in Binary Table and add the Exe file you just downloaded Add the following string to the "Command Line"-Option in your Custom Action : "/passive /norestart /showrmui /LCID [ProductLanguage]" (no quotes) This will show a passive progress dialog of the .Net installation. Use "/q /norestart /showrmui" (no quotes) instead if you don't want to show anything to the user Run the CustomAction after "InstallFinalize" and execute it when the .Net Version from the Registry Key is lower than the one you require (in your case this would be: NOT REMOVE~="ALL" AND NOT PROP_DOTNET_INSTALLED_VERSION >= 461808) Depending on your setup design, you can(should?) add a Checkbox in your dialogue so the user can decide if he wants to install missing .NET during the setup or all by himself afterwards.
... View more
Dec 13, 2019
03:51 PM
I think I might found a bug in Installshield that causes this behaviour: When you pass MSI Logfile Options with the /V Parameter AND the path to the MSI logfile contains a dot(!) WHILE your doing a MajorUpgrade operation, Installshield will keep the broken Add/Remove Programs entry in the registry. You can reproduct this behaviour with any setup.exe that is created from a Installscript MSI project (might affect other project types, but I didn't test them so far): Make a setup and generate two different versions (eg 1.0.0 and 2.0.0) Create a path with dots, eg. C:\path.with.dots\ run the Setup with following argument Setup.exe /V" /L*v!"""C:\path.with.dots\setup.log"""" This error doesn't reproduce when working with a .msi file, so it seems to be a problem with the IS Bootstrapper. My current workaround will be saving those files to a path that doesn't contain dots (like C:\Windows\Temp) and copy the file back to where I want it after the installation
... View more
- Tags:
- bug
Dec 13, 2019
06:46 AM
Hi, Im currenty developing a MSI InstallScript Setup. To avoid most of the problems associated with MSI, I'm only using MajorUpgrades as the upgrading procedure with RemoveExistingProduct running before InstallInitialize to have a clean environment everytime. RemoveExistingProducts however only removes ...\Uninstall\{ProductCode} registry key from the System and leaves the \Uninstall\Installshield_{ProductCode} key. Because of this, a broken Link remains in the Add/Remove Programms DIalog in the Control Panel So far I've checked following: Running everything with Admin rights Advise from KB in: https://community.flexera.com/t5/InstallShield-Knowledge-Base/Major-upgrade-leaves-2-entries-in-Programs-and-Features/ta-p/4325 Actions and Custom Actions all return 0 or 1 All Features and Components are marked for removal in InstallValidate MSI (s) (xx:xx) [xx:xx:xx:xxx]: Feature: feature1; Installed: Local; Request: Absent; Action: Absent MSI (s) (xx:xx) [xx:xx:xx:xxx]: Component: comp1; Installed: Local; Request: Absent; Action: Absent All Components are Unregistered properly and all the correspondig registry keys are removed from ...\Installer\UserData and HKCR\Installer : MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: ActionStart(Name=ProcessComponents,Description=Updating component registration,) MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: ProgressTotal(Total=x,Type=1,ByteEquivalent=24000) MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: UnregisterSharedComponentProvider(Component={GUID},ProductCode={GUID}) MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: ComponentUnregister(ComponentId={GUID},,BinaryType=0,) All Components are Unregistered properly and all the correspondig registry keys are removed from ...\Installer\UserData and HKCR\Installer MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: ActionStart(Name=UnpublishFeatures,Description=Unpublishing product features,Template=Feature: [1]) MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: FeatureUnpublish(Feature=feature1,,Absent=2,) MSI (s) (xx:xx) [xx:xx:xx:xxx]: Note: 1: 1402 2: UNKNOWN\Installer\Features\GUID 3: 2 All Files and folders are "removed" from the system (more on error 2318 later) MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: SetTargetFolder(Folder=C:\xx\xx) MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: FileRemove(,FileName=file1.dll,,ComponentId={GUID}) MSI (s) (xx:xx) [xx:xx:xx:xxx]: Verifying accessibility of file: file1.dll MSI (s) (xx:xx) [xx:xx:xx:xxx]: Note: 1: 2318 2: MSI (s) (xx:xx) [xx:xx:xx:xxx]: Note: 1: 2318 2: I'm testing those Installations in a virtual machine with full admin privilege and revert to a snapshot when I encounter that error, so this isn't caused by older installation. All my CustomActions have "NOT UPGRADINGPRODUCTCODE" in their condition and none of them is getting executed When I create a new test project I don't have this problem. The only difference in the Log file are the two "Note: 1: 2318 2:" messages behind the file removal are missing. This tells me that, even when MSI is able to remove all of the files, it "thinks" it doesn't have the rights to open them. Can anyone confirm my suspicions, has a solution or a better explanation for this behaviour? Thanks in advance! (I removed some of the data that mightbe considered sensitive.)
... View more
Labels
- Labels:
-
InstallShield 2018
Latest posts by SemmlTim
Subject | Views | Posted |
---|---|---|
5087 | Dec 16, 2019 08:18 AM | |
1036 | Dec 13, 2019 03:51 PM | |
1064 | Dec 13, 2019 06:46 AM |
Activity Feed
- Posted Re: Install .NET Framework 4.7.2 on InstallShield Forum. Dec 16, 2019 08:18 AM
- Posted Re: Problem caused by possible bug on InstallShield Forum. Dec 13, 2019 03:51 PM
- Tagged Re: Problem caused by possible bug on InstallShield Forum. Dec 13, 2019 03:51 PM
- Posted RemoveExistingProdcut leaves second Registry Key (Installshield_{ProductCode}), leading to broken Control Panel entry (Error 2318?) on InstallShield Forum. Dec 13, 2019 06:46 AM