Re: Installshiled 2019 Premier Trail Evaluation Questions

SunnySun · ‎May 07, 2019

I have evaluated Installshield 2019 Trial today. Some questions below.  About .netFramework 3.5: 1. When I install it on clean Windows 10 x64 system, it will try to install .netFramework 3.5 after InstallShield 2019 installed. I don’t know if .netFramework 3.5 has been installed successfully though it prompts succeeded finally. 2. From my point of view, Windows 10 contains higher version of .netFramework already, .netFramework 3.5 should not be triggered during IS installation. 3. During my building my project, the digital signature won’t be successful since it says .netFramework 3.5 requried to be installed. Then I can only install it on another Windows 7 system. Does it mean InstallShield 2019 couldn’t work as expected on Windows 10 system?  I have basic msi project created with IS2009. After switch the project into IS2019, I build the release. There are some difference with the output installer structure. -> All mst,ini,msi files are located in the same folder as the Setup.exe when build release with the old version IS2009. ->All mst,ini,msi files are invisible, seems they are all compressed into the Setup.exe by default when build release with IS2019. I set to be uncompressed for compression selection as the attached screenshot. Want to know if the default behavior of IS2019 to compress those files into Setup.exe? Is there any way to make those files(All mst,ini,msi files) visible from the release folder same as the Setup.exe?

banna_k · ‎May 07, 2019

@SunnySun :

Installshield requires .netFramework 3.5, some of the Installshield utilities are targeting to .netFramework 3.5 specifically, these utilities wont function properly even the system has higher version of .netFramework. And Installshield works on Windows 10 system without any issue.

Hope you are verifying with the evaluation version of the Installshield 2019, there is a difference with the output installer structure with the evaluation version. Evaluation version always create the compressed setup.

SunnySun · ‎May 08, 2019

Thanks for the swift feedback! Now, I can't make it work well on my Windows 10 system since it will always prompt the .netFramework3.5 requried during digital signature. But it had ever been installed during Installshiled installation though I can't find it from ARP entry. If I install it by manually, it will always fail because higher version is already installed. Then how can I get Installshiled to work correctly on Windows 10? Regarding the second issue, I need to check if one issue is fixed in Installshield 2019. I can't install successfully because the the compressed setup. Reason is as below: With a compressed setup, the installer will extract to %TEMP% folder during installation, then the [SourceDir] would be C:\Users\username\AppData\Local\Temp\{GUID}\'. But [SourceDir] is used in our installer for specifying those chained msi's location which is same location with the Setup.exe and also for the msi file if it is uncompressed. So what can I do to avoid this then make a successful installation with the Evaluation version except to change the [sourceDir] in my project file since there are so many reference in my project. Please give advise, thanks! BR, Sunny

SunnySun · ‎May 08, 2019

In another words, could the evaluation version build chained MSI then perform successful installation?

Jenifer · ‎May 08, 2019

Hi @SunnySun ,

Did you try installing .NET 3.5 with dism commandline ?The below article can help you with doing that:

https://windowsreport.com/net-framework-3-5-missing-windows-10/

To know why .NET 3.5 isn't getting installed via InstallShield setup you can run setup with /debuglog commandline and attach installshield.log here.

You can give it a try in evaluation version to check whether chained MSI works with that or not,i hope it might work

Thanks,

Jenifer

SunnySun · ‎May 08, 2019

Hello Jenifer, Thanks a lot for the information! I will try your solution about .netFrameWork 3.5 on Windows 10 later. Regarding the Chained msi in evaluation version, some points from my side: 1.We have chained msi project created with installshield old version. With old Installshield version, there are some boring bugs then currently we want to update to latest Installshield 2019 and need to evaluate firstly if those bugs have been fixed in your new Installshield 2019 version. 2.As you told me, evaluation version will always output the compressed setup.exe even if I select uncomperssed. 3.After switching to installshield 2019 and some related changes according to the build error, my project could be built successfully without any problem, the only difference is as said in my original post: Those MST,ini,msi files are compressed into Setup.exe instead of unpressed. But all sub chained MSI's won't be compressed into Setup.exe, still be left in their specified folders. 4.The chained package could not be installed because they can't be found from the specified location. Log file shows as below: MSI (s) (9C:F8) [10:13:04:233]: ******* RunEngine: ******* Product: C:\Users\CT Mas\AppData\Local\Temp\{E76BA373-A8AD-4271-B90D-C830B116E9C3}\applications\sample\sample.msi ******* Action: ******* CommandLine: ********** MSI (s) (9C:F8) [10:13:04:233]: Note: 1: 2203 2: C:\Users\CT Mas\AppData\Local\Temp\{E76BA373-A8AD-4271-B90D-C830B116E9C3}\applications\sample\sample.msi 3: -2147287037 MSI (s) (9C:F8) [10:13:04:233]: MainEngineThread is returning 3 MSI (c) (24:CC) [10:13:04:233]: Decrementing counter to disable shut -> That is caused the super package is compressed, while chained packages is not compressed. -> As you know, all chained msi's should specify their location like attached "sourcedir.png". -> If the whole package is uncompressed, the chained msi will be called as expected by the super msi which locates at same folder ([sourcedir])as Setup.exe and the will not be a random folder which extracted during installation. -> As the evaluation version only output the compressed Setup.exe, while chained msi's wont' be compressed into Setup.exe at the same time. During installation, the compressed package extracted those things(msi...) to the temparory folder(C:\Users\CT Mas\AppData\Local\Temp\{E76BA373-A8AD-4271-B90D-C830B116E9C3}) which will be the location of [SourceDir] in MSI, while those Chained MSI won't be there since they are not compressed into Setup.exe(they only exist in the same folder with Setup.exe,e.g. D:\DiskImages\Disk\Setup.exe;D:\DiskImages\Disk\applications\sample.msi). I don't think out of any ways to make it install successfully. Could you please provide the way to make my chained MSi's installed successfully with an evaluation Installshield 2019 version?

Jenifer · ‎May 22, 2019

Hi @SunnySun ,

I could say having [SourceDir] as a path for picking msi in Chained Msi->Installation(run-time path) might not be a good idea.

Why?

On building installshield project SourceDir which is here:"C:\InstallShield <Version>Projects\<Project Name>\<Product Configuration>\<Release>\DiskImages\Disk1" will be refreshed every time.Hence you might not get the msi referred from here.

But in the case on giving "No" to the prompt to specify whether you want to stream the .msi package—and its uncompressed files, if the .msi package is not compressed—into your product's main .msi package:

Value [SourceDir]Name.msi will be autopicked by InstallShield. Which means you have to place the needed chained msi in directory where your setup.exe resides.(Which you would launch for installation)

About the issue why it isn't getting installed,can you please attach actual msi log here?

Update:

Could reproduce the issue that you face with making release as compressed.Could see in both compressed and uncompressed logs the value of SourceDir getting changed.Attaching snapshots:First one is compressed,second one is uncompressed

The value of compressed setup might be changing due to the introduction of prevention of DLL preloading as given in the KB-Article

https://community.flexera.com/t5/InstallShield-Knowledge/Windows-loads-a-different-library-or-launches-a-different/ta-p/4739

Uncompressed setup works without any issues.

Thanks,

Jenifer

SunnySun · ‎May 23, 2019

Hi Jenifer,

Thanks for not forgeting my thead and those useful information. 🙂

I know "Uncompressed setup works without any issues." exactly with non-evaluation version.

But I am evaluating Installshield Premier Trial version now. Iin your first reply, "there is a difference with the output installer structure with the evaluation version. Evaluation version always create the compressed setup. ".

Regarding the installation failure, I know the reason :The chained package could not be installed because they can't be found from the specified location. Log file I had already post last time.

MSI (s) (9C:F8) [10:13:04:233]: ******* RunEngine: ******* Product: C:\Users\CT Mas\AppData\Local\Temp\{E76BA373-A8AD-4271-B90D-C830B116E9C3}\applications\sample\sample.msi ******* Action: ******* CommandLine: ********** MSI (s) (9C:F8) [10:13:04:233]: Note: 1: 2203 2: C:\Users\CT Mas\AppData\Local\Temp\{E76BA373-A8AD-4271-B90D-C830B116E9C3}\applications\sample\sample.msi 3: -2147287037 MSI (s) (9C:F8) [10:13:04:233]: MainEngineThread is returning 3 MSI (c) (24:CC) [10:13:04:233]: Decrementing counter to disable shut

So I only want to know, how can I get my chained MSI's to be installed successfully with an evaluation version- compressed Setup.exe output. My chained MSI's are not streamed into main packages because of big size. Could you please give some hints about which should I set to the Installation(run-time path) for a Trial version?

I need to know if some bugs in old Installshield version are fixed in Installshield 2019 with this evaluation. Thanks.

Best Regards,

Sunny