Installshield has the option of selecting software requirements or redistributable prerequisites. I can't figure out whether my dependencies need to go in one or the other (say Adobe Reader/.NET framework).
What is the rationale behind the two possibilities?
They vary in what the run time behavior will be. To summarize, a redistributable prerequisite (when written correctly) will check for the presence of some piece of software and install it if it is not present. A requirement will add a launch condition to the MSI package that will check for the presence of some piece of software and abort the main installation if it is not present.
If there's any chance that someone may end up with access to a raw .msi file, it's a good practice to include the corresponding software requirement for any prerequisite your program needs, even when you include it in setup.exe. That way, if they don't launch from setup.exe, they can still find out about any unmet dependencies.
Related
I used Flexera's InstallShield Express to bundle my software into a Setup.exe file. I included .NET Framework 4.7.1 redistributable (2. Specify Application Data > 'Microsoft .NET Framework 4.7.1 Full' is checked and highlighted in middle panel, and says 'installed locally' > 'Install before feature selection' is checked on bottom panel).
I went onto my fresh installed Windows 7 computer with no internet access and attempted the install. It gave me the error:
"An error occurred while downloading the file
http://saturn.installshield.com/is/prerequisites/Microsoft.NET Framework 4.7.1 Full.prq"
I then connected to the internet, and it was able to go through. I looked for a text of the prq. There may be a way to find it thru InstallShield, but I found a forum post from community.flexerasoftware.com asking about 4.7.2.
The two parts of interest are:
<file LocalFile="<ISProductFolder>
\SetupPrerequisites\Microsoft .net\4.7.1\Full\NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
URL="https://download.microsoft.com/download
/6/E/4/6E48E8AB-DC00-419E-9704-06DD46E5F81D/NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
FileSize="0,0"/>
and
<properties Id="{BFF4A593-74C5-482F-9771-7495035EBBB0}"
Description="This prerequisite installs the .NET Framework 4.7.2 Full standalone package."
AltPrqURL="http://saturn.installshield.com/is/prerequisites
/Microsoft .NET Framework 4.7.2 Full.prq"/>
The fact that the file reads '4.7.1' is another can of worms I need to explore (not in the scope of this question). I'm assuming all prq files have a common structure. I believe that this information tells me the URL (download.microsoft.com) was skipped and the AltPrqUril (saturn.installshield.com) was used during my install. But even if the URL were not skipped, it would still looking at a page on the world wide web.
Question
Why do I need internet connection? The 'Full' version is specifically different from the 'Web' version in that you do not have to connect to the internet to install it.
Avoiding Internet Connection Requirement
To embed runtimes in the setup.exe and hence avoid the need for
an Internet connection, you can try to set the option "Extract
prerequisites from setup.exe" in the setup.exe tab in the
Release view as illustrated in the second screenshot below.
Then you select the "Full" .NET Framework version in the
Prerequisites View. Not 100% sure what features the Installshield Express version has vs the full versions. The below is from the Premier version.
You can check your finished bundle, by doing a "setup.exe /a" -
from a command prompt - on the final
setup.exe and extract the files to see what is really included in the bundle.
Quick Reminder
I think you should generally call Installshield support if you have a support agreement, or check their own community at: https://community.flexerasoftware.com.
Just mentioning this since people sometimes forget to check whether they have support agreements and support & community might resolve your problems in 5 minutes - if you don't get answers here.
Release Wizard
However, just shooting from the hip I would propose that the cause could be this setting that is available in the Release Wizard in the regular version of Installshield 2018. It is probably similar in the Express edition:
In the Release property pages, it seems this setting is under the Setup.exe tab and it is called "Installshield Prerequisites Location":
[
Prefer Download
For what it is worth I really dislike old, outdated runtimes included in bloated setups. This has to do with my experience as a corporate deployment specialists where much of the day consisted of extracting outdated runtimes from vendor packages.
I would always suggest you download very common runtimes from the web, or allow them to be installed via Windows Update. That includes basically all Microsoft runtimes.
I only like to bundle runtimes if they are 1) Rare and special, 2) Stable and well tested, 3) Small and well-behaving. Even then I would prefer them downloaded and installed separately - to allow security fixes to be installed without rebuilding your whole setup - you just put up the new runtime version on your server (marketing will want a new build for physical release - that is just added risk if you ask me).
War story: the SOAP merge module - back in the day - almost destroyed my package with global deployment scope. Deployment errors quadrupled. Prerequisites can really ruin your work, and you will face little understanding for the problem seen. Try to make it clear what breaks and why. And get rid of all prerequisites you can (pie-in-the-sky thinking, I know). Certain runtimes are unavoidable of course. I just ramble on :-).
I'm installing Visual C++ Redistributable 2013 as a prerequisite (if its not installed)through my installer. But sometimes already installed VC++ is corrupted then my installer does not work because I'm having DLL functions called in CustomAction.
So my question : Is there any way to find whether the installed VC++ redistributables is corrupted or not ?
Health checks in general are a pretty difficult topic. For files built into Windows, there are tools like SFC, but that doesn't extend to other installed packages. For MSI packages, you can choose to run repair, and in some cases Windows will do this automatically; this topic in general is called Resiliency. But unless auto- or manual-repair fixes the sorts of problems you encounter in the wild, it's not very relevant.
So the question becomes what sorts of problems do you actually encounter, with what frequency, what their fix is, and what problems can be caused by attempting to fix them. If it's sufficient to invoke a manual repair of the VC++ redist, that's fairly easy to implement. If a full uninstall and reinstall is required, that's much more invasive; the idea of making that part of an installation rubs me the wrong way. If you have to do this only in very specific situations, it may depend on how well you can identify those situations.
Alternately, if your focus is ensuring that your installation succeeds, you may be able to statically link your custom action DLLs so that they no longer depend on the state of the VC++ package. This will not help your application much if the application also depends on the VC++ package, however. Perhaps a privatized copy of the VC++ DLLs can address that (if the 2013 version supports that--I forget), at the cost of more difficulties servicing your copy of the VC++ DLLs in case of security updates.
But again, this all depends on what sorts of problems occur, whether they're frequent enough to merit addressing them, and whether the cure is worse than the disease.
I have a software that is coded in C#. It depends on two(!) third party dll which require Visual C++ 2008 and Visual C++ 2005 redistribute. Originally the installer was built in InnoSetup with all "vs200x_sp1_vcredist_x??.exe" embedded and run on install time. However since it lacks of some advanced features we decided to migrate to Wix Toolset.
The problem is, MSI was running in a more restricted environment, so I didn't figure out what is the best way to require those redistributable file being executed properly. I was tried to use merge modules instead but it didn't work - I can see that the files were installed but dependency walker shows that dll is still not link to the right version.
I think that WinSxS makes things worse at least in this case, since the software keep failing with some error message regarding "Windows Side by Side configiration (14001)" when I use the merge module approach.
So the question is:
Are there any way to build a MSI that runs a exe that install some prerequisites? I wouldn't mind those prerequisites being downloaded or just embedded.
I know that WinSxS information is stored in the manifest of the dll. So if I was permitted to remove the manifest information by the third party company, and use dynamic dll loading instead the problem could be resolved. However is this legitimate? Since I will then need to embedded the Microsoft dlls directally in the msi.
I have noticed one of the dll's manifest says its required version is "9.0.21022.8" but the one in my MSM file is "9.0.30729.6161". Is this the issue? If so can I resolve the issue by I modifying the manifest to allow the right version? I don't think this will cause the dll not working, anyway.
The msi file should install only your software. If you need to install pre-requisites, you should use a bootstrapper for it. Bootstrapper's responsibility is to install pre-requisites and it's not a task of your msi.
If you see that wix bootstrapper is complex you can try on a simple bootstrapper like the dotnet installer bootstraper. you can download it from
http://dblock.github.io/dotnetinstaller/
I'm using third party libraries that I obtained well before KB2465367 came out. My development computer has been updated with KB2465367 so all the binaries I generate seem to now be dependant on 8.0.50727.5592 of the CRT (the 2465367 version of the CRT).
Now, when I want to deploy this application I'm using the 8.0 CRT merge module (also updated by 2465367). This installs 8.0.50727.5592 versions of MSVC libraries (like msvcrt80.dll).
But, when I run my application on a machine that's never had the VC runtime installed, it complains about "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." I've traced this back to a system entry in the event log: "Generate Activation Context failed for C:\Program Files\MyCompany\MyApp.exe. Reference error message: The operation completed successfully." under the source "SideBySide".
Of course, this update has basically meant I'm dead in the water.
How do I proceed from here? Do my clients need to install 8.0.50608.0 version of the CRT after installing my application because the 3rd party libraries need 8.0.50608.0 and the MSM I used didn't include it?
In my circumstance I'm using How To: Install the Visual C++ Redistributable with your installer which only describes using a single MSM. It's recommended that a policy MSM also be used to redirect any DLLs dependant on older versions of the runtime.
See also http://lynk.at/jlqsKx
This is the same thing happened when MS rolled out KB971090.
A simple solution is to remove the KB2465367.
You can reference more information about KB971090 and KB2465367 at here.
There is an uninitialized data bug in the patch that can cause DLL load failure.
Your installation program have to use two merge modules:
The runtime libraries, and
The policy file which redirects all older versions of the runtime to the new version.
The redistributable package vcredist_xxx.exe installs both the latest version of the libraries and the policy files.
You cannot assume the VC libraries are available on users machines, therefore you always have to install them. Otherwise your application won't run.
I have an application that uses the ms vc++ runtime. How should I install it on the end-user's system if it is not present? I was thinking of bundling it with the installer... but how would I do that as far as what to include? Is there some silent installer? If so, where can it be found? I can't seem to find it in the Windows SDK.
There is an interesting post about deploying the runtime libraries on the Visual C++ blog. The post is about VC8 so I'm not sure all the recommendations apply to VC9.
Here are your options according to Microsoft:
Use an .msi installer including the .MSM files for the VC
libraries you're using. These MSM
files install the libraries globally.
They also keep a reference count so
that the libraries are removed when
the last application using them gets
uninstalled.
Use "app-local"
deployment i.e. copy the
libraries and manifest files in your
application directory. This is a simpler
solution if you don't use an .msi
installer. Your app should still use the
system version of the libraries if they are more
up-to-date than your own.
Link everything statically (and avoid crt usage across dll boundaries)
Another option Microsoft discourage you from using is running the Visual C++ redist installer from your own installer.
I'm not sure what their reasons are. It will take a few extra megabytes and will not be reference counted but it still works very well AFAICT. You can pass the /q option to vc_redist_x86.exe to perform an unattended install (no user interaction).
It has it's own installation program. I've seen it usually run as a prereq step of a larger installer.
One way or the other, you need to list it in your manifest. So you might just as well deliver it as via SxS in your application rather than try to deliver a global copy to the target machine. SxS is a big hard subject, sadly. Hopefully someone will supply an answer with more details and I'll delete this one.