We are migrating our applications from 32 bit to 64 bit. And also .net framework 3.5 to 4.0.+Visual Studio 2008 to Visual Studio 2010
Aspart of migration we created all msi's in 64 bit with visul studio 2010. we had a problem while installing them.
we are getting System.BadImage error for the msi's which are having some customaction condigured in depolyment project. Due to this error installation rolled backed.
Root Casue Identified:
For doing customaction we have projects with installer classes While installing those using msi we caught that error.
When ever we get that error.We just tried installing that .exe manually using 64 bit visual studio commandLine with installUtil.exe command. it successfully installed.
But when we are using 32 bit visual studio commandLine with installUtil.exe, we end up with the same error.
So problem is when ever we are using msi its picking the 32 bit installUtil.exe eventough the msi is 64 bit which is causing the problem.
Tried Solutions:
1.Tried debugging the installer class using Debugger.Launch(). But before hitting the point we end up with error.
2.Try to edit the Database table of msi with orca editor to pick the correct version of installUtil.exe. But failed with other error.
Question:
1.How can we modify our solutions to pick the 64 bit installUtil.exe?(if we can do this)
Rule #1: Don't reinvent the wheel. Avoid CA's wherever possible.(See PhilDW's answer)
Rule #2: When you really must use a managed custom action don't use InstallUtil. Use Windows Installer XML (WiX) Deployment Tools Foundation (DTF) instead.
Rule #3: Write custom actions that follow MSI's transactional model (Install, Rollback, Commit) whenever possible.
Rule #4: Write data driven, declarative (custom tables) custom actions whenever possible.
Rule #5: Honor the security model of MSI ( custom actions that change data must be deferred in the system context )
Rule #6: Test the !#Q%Q! out of your CA's. Make sure that install, uninstall, reinstall, cancel (rollback ) and upgrade (and upgrade rollback), repair and silent installs all work as expected. Hint: Rule #1 exists because you get this for free when you don't write custom actions.
Reference:
Deployment Tools Foundation (DTF) Managed Custom Actions
This might be the issue:
http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
You don't need installer classes. Visual Studio setups to generate MSI files are not in newer versions of VS, so you should use a tool that uses the standard methods of installing services, ServiceInstall and ServiceControl being the underlying tables in the MSI file.
Related
I have been pulling out what's left of my hair trying to install software that requires a C++ redistributable (2017 x86) using InstallShield lite.
To start with, I define a prerequisite To include the C++ redistributable. When a user attempts an install, the user interface always appears. Now this is not a real problem however, if the redistributable was already installed`or there is a newer version then it will fail with a message that it has failed and it wioll ask the user if he wants to continue or abort the installation. If he selects continue, the software installs fine. This is not very user friendly.
This happens despite the correct command line switches being used i.e. /q /norestart. If you do this at a command prompt manually, it operates as it should. In other words it installs it, or fails because it is already installed but tells the user nothing. This is the way it is supposed to work.
Now I tried doing this as a custom action at the end of the installshield script but then the install appears to hang on some machines and on others other errors.
Now the only clue that I can give, is that if I create an MSI installation, then it never prompts. However with a setup.exe install it acts as above. I have only been successful with the msi install if I am installing a 64 bit app. Never with a 32 bit app.
Can someone guide me as to what I am doing incorrectly?
Thanks
VCRedist: This C / C++ runtime (in various versions and flavors) is a pain indeed. I decided to write something up a while back to try to summarize a few things:
Wix per user installer to detect the Visual C++ 2015 Redistributable (please skim at least - not great, better than nothing I hope - deals mostly with detecting the presence of the runtime).
Merge Modules: Does Installshield Lite support merge modules? If so, you can install the VCRedist using merge modules instead of the VCRedist_x64.exe file. This is insufficient for UWP applications (the universal CRT) as explained in these links:
Redistributables for deploying C++ exe developed with Visual Studio 2015 on Windows 7
WIX merge c++ runtime
Do read the links directly above - they are quick reads.
Batch File: Another option would be to keep the VCRedist_x64.exe file separate from your main setup and to zip up your MSI and the VCRedist_x64.exe in a ZIP archive and put an Install.cmd batch file in there which will install the VCRedist first and then your MSI file? Not too neat - one would have to admit. I think you can make a self-extracting archive that would automagically invoke it, but I haven't done that in ages.
Just a mock-up batch file from link below (untested):
REM 1. Install VCRuntime
vc_redist.x64.exe /install /quiet /log "%temp%\Install_vc_redist_2017_x64.log"
REM 2. Install MSI
msiexec.exe /i MySetup.msi /L*v C:\MySetup.log /QN
Not sure about security fixes and that kind of stuff. Run Windows Update afterwards?
Security Fixes & Link to Download: There have been so many security fixes for this runtime, and it is usually installed on most machines, that I would frankly just link to the download of the latest version and have people install it themselves as a pre-requisite rather than bundling an obsolete version in my setup, but that isn't really sufficient unless your package is for corporate use only (in which case they prefer to install their own runtimes with full control).
Some Links (to find easily):
Command lines to install and uninstall silently the VC++ 2017 Redistribuables (installation command lines, untested by me)
The latest supported Visual C++ downloads (please check)
Microsoft Visual C++ 2017 Resitributable Package (x86) (please do read this)
How to prevent vc_redist.x##.exe (VS2017) from ambiguously failing due to pending reboot?
Visual Studio 2017 Installer Project - include VC++ 2015 Redistributable
There is always the WiX toolkit
Distributable Code for Microsoft Visual Studio 2017 (Includes Utilities, Extensibility, and BuildServer Files)
Mailbag: How to perform a silent install of the Visual C++ 2010 redistributable packages
Thanks for a comprehensive answer. I am sure it will help a lot of people. What I have found is that running vc_redist.x86 from the command line in quiet mode will indeed always work as it should. In other words, if it is not installed, it will be installed. If it is already installed or a later release is installed, it will just return with no complaints. That is not the case using InstallShield Lite 2018 (same for all previous releases).
However, there is a simple solution to get it to work as I found out. All one needs to do is to include the entry Hidden="1" in the behavior part of the PRQ file. So there will now be an entry that looks like this:
<behavior Hidden="1" Failure="4" Reboot="2"/>
This solves the issue. It no longer runs separately from the installshield installer with it's own GUI but rather the messages now appear in the menus in installshield and it operates exactly as if you ran it at the command line. No more errors.
I have a redistributable msi my program needs to be able to run. So far I've created a launch condition. The condition it uses is under "Search Target Machine". This needs a component ID.
This page suggests I can only determine the component ID via MSI Spy, a tool that as far as I can tell is no longer available: https://msdn.microsoft.com/en-us/library/1s08hzfe(v=vs.80).aspx
I must use a Visual Studio Setup Project, and I must distribute the 64 bit end user runtime of slimdx from http://slimdx.org/download.php.
How can I successfully get a component ID, or alternately how can I bundle an msi as a prerequisite?
MSI Spy seems an odd choice! The "standard" tool for looking in MSI files is Orca, supplied in the Windows SDK/Kit, install from Orca.msi. There are others if you search.
Look in that MSI and go to the Component table, look for a component id that is always installed (if that can be determined) and use that guid.
Ths might help with the custom prereqs:
Adding Custom prerequsites to visual studio setup project
and support for custom prerequisites in setup projects has never bneen particularly good, even when the Bootstrap Manifest Generator was around.
This might be useful if you can figure out how to alter the manifest file to add your custom prerequisite, which is what the BMG tool did.
How to install redistributable with visual studio setup?
I'm using the Visual Studio Setup project. If I go to the properties of the Setup project, it lets me choose which pre-reqs are required, at which point I choose the C++ Redistributable.
On some systems, this works fine - but recently my users are reporting that the install failed because "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
What's the proper way to do this? Is Visual Studio's detection fouled up somehow and unable to detect C++?
Yuck, this is ugly. I was wondering what would happen after Microsoft gave up on the side-by-side install of the runtime DLLs for VS2010. Seems clear, the interwebs are full of this installer error. The biggest victim seems to be Microsoft itself with Streets and Maps failing to install.
I'm not aware of any security patches for it so I have to guess that you haven't updated to SP1 yet. And your customers use a product of a vendor that did. This is a battle that you're always going to lose some day. Do consider taking advantage of the app-local deployment for the DLLs, copying them in the same directory as your main EXE. Simply copy them from the vc/redist directory before putting the setup package together, no need to tick the prerequisite. You'll need:
msvcr100.dll and msvcp100.dll for the regular CRT
atl100.dll if you use ATL
mfc100.dll, mfc100u.dll, mfcm100.dll, mfc100u.dll if you use MFC (u = Unicode, m = managed)
mfc100xxx.dll where xxx is the 3 letter language code if you use MFC on a non-English machine
vcomp100.dll if you use OpenMP in your code.
Only disadvantage is that they won't get updated if there's a security patch. That could be an advantage too, depending on what color glasses you wear. If you're uncomfortable about it then keeping the machine that creates the setup package updated, including enabling Windows Update, is an important requirement.
The default Visual C++ 2010 Redistributable uses a Product Code for detection. So Visual C++ 2010 SP1 Redistributable is not detected as installed. This is why the package tries to install it and fails.
A good solution is to create your own custom prerequisite which uses a better detection criteria. Here is an article which may help you:
http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx
Visual Studio setup projects do not support custom prerequisite creation. However, it can be done by manually generating the required manifests.
You can find the manifests structure here: http://msdn.microsoft.com/en-us/library/ms229223(VS.80).aspx
These manifests can be generated automatically with the Bootstrapper Manifest Generator tool.
After generating the package manifests, you can add all these files (including the package) in a separate folder in the Visual Studio prerequisites folder, for example:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\
This way Visual Studio will show the prerequisite in your setup project properties page.
I have custom bootstrappers for SQL Server 2008 R2, .NET Framework 3.5, .NET Framework 4, etc. I am using Visual STudio 2010's Deployment project to deploy a .NET 4 application. I know these are going away.
Is there a way I can specify a bootstrapper to Fail if the user does not have specific Windows Privledges? SQL Server's Setup seems to take care of this on its own, but gives very cryptic error codes and texts that are hard to trace for users. I know that I can set Bypasses for Windows versions, and SqlCheck.exe performs some sort of version check. Would I have to create my own application that checks the user's permissions, and the bootstrapper could check the return code of that, similar to SqlCheck.exe?
Can this be accomplished using the Bootstrapper Manifest Generator, and is the BMG even supported by Visual Studio 2010? Appears to not be supported anymore, but I"m not sure if there's anything specific to VS 2010 / Windows Installer 4.5
http://archive.msdn.microsoft.com/bmg
The most you can do with the standard Visual Studio bootstrapper is to check the AdminUser property value. The predefined .NET Framework 4.0 Client Profile prerequisite uses a similar condition. You can find its manifest in this folder:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client
This should also be supported by the bootstrapper manifest generator.
But, and this is a big one, on newer Windows versions all users can get Administrator privileges through elevation. So from the installer point of view, any user is seen as an Administrator, even if he's not.
So this approach is pretty much useless on Vista or higher.
You could try creating your own custom EXE bootstrapper which handles prerequisites and checks user privileges. But you will most likely encounter the same problem.
From my experience, the best approach is to let each installer elevate itself if necessary. Most of them have built-in mechanisms for this, especially the ones from Microsoft.
If you encounter problems with this approach, I'm pretty sure they are not caused by privileges. Most likely your prerequisite is not configured correctly (for example an incorrect command line).
I have an app that on first installer run needs a boostrapper where you can choose the language of the installed app, install .net framework if it's not there yet and some other prerequisites.
I've taken a look at the WiX How To: Install the .NET Framework Using a Bootstrapper
but I don't see how to use this for other custom prerequisites.
What's the best bootstrapper to use for this?
After the app is installed we have an update check on the app startup. if a new version exists we need to download it and upgrade the software.
This wouldn't be a silent upgrade because the EULA and some other stuff might change in the meantime so we still need a GUI for those checks in the updater msi. So i'm considering different options on how to do this.
My first thought was to have 2 separate installers.
The first one would be with the bootstrapper and full GUI, the other would be with minimal GUI for updates.
Is there a better option?
I'd also like the access to the update installer on the to be limited to only users that have the software actually installed.
i'm not quite sure of the best way to do this.
I'm familiar with the WiX upgrade process itself with the upgrade code etc... so that's not the issue.
I'm just looking for a way to design all this in the best way possible.
Any ideas are appreciated. I'm using WiX 3.0.5419.0 from Visual Studio 2008.
I've taken a look at the WiX How To:
Install the .NET Framework Using a
Bootstrapper but I don't see how to
use this for other custom
prerequisites.
You can use the same technique (i.e. the msbuild GenerateBootStrapper task) to install custom prerequisites, but you'll have to author your own bootstrapper packages.
One way to do this is to study the existing bootstrapper packages in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ (or the ones in the Windows SDK) and read the documentation of the Bootstrapper Manifest XML format. The bootstrapper generator tool might also be helpful.
As for auto-updating your application: it's not supported by wix. I believe there were once plans to add this functionality under the name clickthrough, but I don't think those plans ever matured. If they did, I can't find any documentation about it.