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 :-).
Related
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/
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
I'm trying to investigate why would my app, written in VC 2008, crash on bare Windows XP with c0000005. It works great on any windows vista and 7. On XP it would crash with no additional info. Below are the details and the result of a few days worth of my headaches, eliminating one reason after another. Here's the details:
I have Win7 ultimate with XP Mode with iexplore 6 and presumably no patches whatsoever.
I install my program and nothing else, since it is supposed to be install-and-run thing with no additional packages needed.
My app has compiled-in VC2008 runtime (using /MT, as opposed to /MD compiler switch)
I'm using firebird embedded, which needs VC2005 (edited, i wrote VC2008 before) libs for itself anyway, so i put them in my app's working dir
when i install VC++ 2008 on this XP Mode machine, it doesn't crash anymore, so debugging this way is impossible
I've narrowed this error's occurence down to the VC2005 runtime - right after i install it my app stops crashing. But i don't know what could be using it's components. When running the release version under VC2008 IDE, nothing shows any vc2005 libs being loaded (weird, if i say so myself).
My app's linker's dependencies lists these (i added only the first two, the rest was there courtesy of VisualStudio): jpeg.lib, gdiplus.lib, kernel32.lib, user32.lib, gdi32.lib, winspool.lib, comdlg32.lib, advapi32.lib, shell32.lib, ole32.lib, oleaut32.lib, uuid.lib, odbc32.lib, odbccp32.lib, comctl32.lib, %(AdditionalDependencies)
I am also using IBPP firebird interface, which loads these dynamically, so they are present in my app's dir (they need msvc?80.dlls):
fbembed.dll, ib_util.dll, icudt30.dll, icuin30.dll, icuuc30.dll, msvcp80.dll, msvcr80.dll
Please advise why would vc2005 runtime be a remedy for my app to not crash on a bare Win XP. Or how could i debug that one without installing vc 2008 on target machine. I'm starting to blame windows xp's components. Ultimately i want my app to not require any additional packages, such as VC2008 or 2005, especially when no component of my app requires the latter.
I am also using IBPP firebird interface ... msvcp80.dll, msvcr80.dll
The answer is in your question, these DLLs are VS2005 runtime support DLLs. They cannot be stored in your exe directory, they must be registered in the side-by-side cache. This does not typically cause an AV, but it isn't impossible if the code doesn't check the return value of LoadLibrary(). You can download an installer for them from Microsoft. It doesn't otherwise have anything to do with Windows XP, you just happened to try to run this program on machines that already had the DLLs installed. Very common on a dev machine for example.
If you don't want a dependency on them then you'll have to rebuild those DLLs that require it. Which is a good idea, having a dependency on more than one version of the CRT is pretty unhealthy.
If you are wondering why you are having to deal with this: it was Microsoft's attempt to put DLL Hell in the developer's lap instead of the user's. They've since withdrawn this, VS2010 again makes it a user problem. That was a pretty big party in Bangalore, I'd imagine.
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.