I am using InstallShield 2015. When I open the Install Script project (ISM file) I do not see where I can set Template Summary property under General Information or any other tab. (I want to make it a 64 bit-only installer.)
I can set it under General Information tab when I open the MSI file but the MSI file gets overwritten every time I build the ISM file.
Is it possible to set it in the ISM file?
You're not clear about your edition of InstallShield, but as you mention opening the built .msi file, I'll assume you are using Professional or Premier. In those editions, you can set the architecture portion of the Template Summary property to 64-bit by replacing Intel with x64 in either the Summary Information Stream section of the General Information view, or in a Product Configuration in the Releases view. The latter overrides the former, so if you inherited a project that used the latter, you might think the former is failing.
See Targeting 64-Bit Operating Systems with Basic MSI and InstallScript MSI Installations in the InstallShield help for this and additional information.
Related
I've been looking into the Qt installer framework but when you create a setup using this tool it is a regular setup though I was wondering whether it would be possible to create an msi setup to be able to install a Qt program network wide.
I've looked at the installer framework docs but was unable to find anything about this so far.
Qt installer framework doesn't provide creating of MSI installer. For MSIs you should use WiX for example.
You have got a proper answer, maybe I'll add some further links for you. Before I do that I can verify that WiX can be used to make MSI installers for any type of Windows application.
There are also a few other tools available to make MSI files that you might want to look at depending on your needs - both open source (free) and commercial. Though WiX is very flexible and great when you have it set up, commercial tools can help you get an MSI created much quicker. Have a read below of the different tools and their pros and cons.
Below are a few links for you - I am a "linking monster" :-). If you pardon what looks like shameless self-promotion, it is really a guess as to what you could find useful to get your MSI file created:
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc (various MSI tools with description of pros and cons)
Windows Installer and the creation of WiX (a little unofficial story of WiX's creation)
WiX "quick start" suggestions (getting started with WiX - not my favorite answer - it is a bit messy - but somehow it seems to be helpful for people)
How do I avoid common design flaws in my WiX / MSI deployment solution? (messy, but may be worth a skim to avoid some problems)
And a few more peripheral links thrown in:
Syntax for guids in WIX? (simplifying WiX source files)
How can I compare the content of two (or more) MSI files? (tools you can use to inspect the compiled MSI files - and some tips for comparing different versions and decompiling MSI files)
Change my component GUID in wix? (understanding the critical component GUID concept in Windows Installer / MSI)
I created the MSI build package for our application. After this installation, we triggered another dependent driver software in the separate process in a committed event of Installer class like below,
Process.Start (" Path of driver software ")
We are facing an issue, installed directory ( It's empty ) folder is not removing while un-installing the same. Actually like installation, we triggered the un-installation of dependent driver software in the separate process by overriding the Uninstall method of installer class.
Anyone, please help me to overcome this issue? How could I remove the installed directory?
I can't change the installation procedure, since we are aware that we can't process another installation/un-installation when another one is going.
You are running a non-MSI driver install EXE from within your MSI? Correct? Or maybe it is an MSI wrapped in an EXE?
Do you have Installshield Premier? Could you use a suite project and install the EXE via the bootstrapper before (or after) the MSI install? I have honestly never used this feature, but running setups in sequence is what it is for. Embedded custom actions in MSI files kicking off EXE files are notoriously unreliable. This is - in my opinion - especially true if you are running with managed code as well (which I think you are).
In the long run managed code may yield safer custom action code (security-wise based on CAS), but for now it seems to cause unwanted runtime dependencies - especially for very large-scale distribution (global distribution) targeting diverse Windows versions (Vista, 7, 8, 10).
I am told it takes a while to get used to Installshield's suite feature, but maybe it is better for you? You can run EXE files, MSI files, patches and zips in sequence. Some fiddling to define uninstall and upgrade behavior I guess and lots of testing. I am pretty sure corporate application packagers would be happy to see a suite rather than an MSI with lots of strange stuff embedded in it.
UPDATE: Once you have compiled a suite setup.exe file it can be extracted as described here: Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file
Alternatively you could try to extract the setup.exe files for the driver setup and install the drivers as regular MSI components and run DPinst.exe to install / uninstall the drivers (tool from DIFx). Also quite clunky - especially when you need to include uninstall.
Your driver setup likely uses DPInst.exe already. I would check if you can extract an MSI from the EXE and use it instead of the EXE to include in the suite project. Some hints for how to deal with setup.exe files (extraction, runtime paramenters etc...): Extract MSI from EXE.
WiX has the Driver element in one of its extensions to deal with driver installs. I have never had the chance to test it.
Due to the administrative privilege of the application, I need to install my program including .exe and .dll in C:\DestFolder\SubFolder\ but I keep getting C:\Program Files\\[Manufacturer]\\[Product Name]\ where the placeholders are specified in the properties window.
I tried this article but no good.
Please don't give me answer like try changing the defaultlocation to C:\Destination\ of the Application Folder as I have already tried. Also I don't want solution like just change the installation destination path manually during the installation.
I have found the answer from this article:
"[ProgramFilesFolder] is built in, and correctly leads to the Program Files directory on the target machine, no matter how customized the setup of Window is..."
There might be tools out there that allow installing outside of Program Files.
[Edit] Infact I've found out this great extension for VS 2017 community called Wix. There's a guy who did a fabulous tutorial on it.
I am currectly finishing my project in C++ and i'm looking for a way to create my own C++ installer file
which will create the project dll's and exe files into a specific path
what is the easier way to learn how to do it?
There are several ways to build an installer. While you can of course always make one yourself, you should google for something like "create an installer". Some prebuilt solutions include "InstallShield", or the ".msi" file format, which you can create on your own using something like "Advanced Installer".
Of course, if you want your users to build your project from source, then you need a makefile and to make sure you bundle all the libraries. There are also kits like autotools to do that for you.
If you use VS 2010, Installshield LE would suffice as it is integrated into VS 2010.
If you have access to Installshield IDE, there is nothing better available for your packaging needs.
There are two ways of packaging:
a) The LEGACY way
b) The Windows Installer way, Basic MSI is the keyword here.
The LEGACY way involves creating your own scripts for:
a) Installing the files to their locations
b) Writing registry entries, if needed
c) Registering COM components, if needed
d) Creating shortcuts etc...
Tools that can be used for LEGACY approach are:
a) NSIS - very good and has a scripting language of its own.
b) Installshield - has a project type called Installscript Project. Installscript is the scripting language to be used.
The Windows Installer way is a bit hard comapred to the LEGACY way.
One has to learn the basics of MSI technology which can be daunting.
The package created has .msi as extension. This file is a database that the developer configures and the Windows Installer takes care of all other things. This is called TRANSACTIONAL installation procedure.
Even the UI presented during install is configured in the Database using tables like Dialog, Controls etc...
Tools that can be used for Windows Installer approach are:
a) Installshield - has a project type called Basic MSI
b) Wix - Opensource and xml based. You configure appropriately named xml files and various utilities in the Wix package will help you to create an MSI package.
First after completing your project click save. Second click on file tab,Add,New Project.
In new Project Click other Project types , Setup and Deployment and in that You can click InstallShield LE or Visual Studio Installer.
Hope this Helped you
I always recommend NSIS. You might also investigate HM Nis Edit - it's an IDE for NSIS that has a useful wizard feature. It will generate an installer script for you which you can further customize. The documentation is extensive.
can't believe no one mentioned install creator pro(there is also a free version with a branded message that displays after installing). Its feature set is pretty limited, though it has options for writing registry values and specifying custom paths to %AppData% or any other place you may want to install some files. it also has an optional wizard interface, and with each step you have the oppurtunity to preview each individual page.
the paid version offers the option for adding serial number/registration to your program. i've never tried it so i'm not sure how effective it may be. its also quite and expensive little program, but i would recommend it atleast to the beginner or someone who is more concerned with maintaining the codebase of their program and less concerned with how fancy and decorated their installer program is.
i know its been a long time since this was posted but for future reference this program is far easier for any beginner to creating installation packages for the first time
I have a VS2008 solution with several libraries and 4 console apps. All build and run correctly in 32 bit mode. The libraries all build and run in x64 mode in another solution with a C# app and a C++/CLI interface layer.
Now I need to build an x64 flavor of the 4 console apps (functional and unit tests for the libraries).
On the Configuration Manager dialog, the Platform dropdown for these 4 projects offers only Win32 as an option. (x64 is also there for the libraries). The Edit and New options are there but do not seem to offer a way to create an x64 choice.
Presumably VS2008 is disallowing x64 for some reason. Is there some other attribute or option I need to set first?
EDIT: Trying to create a new platform in Configuration Manager fails because there already is an x64 platform. It is available to all the library projects.
If you don't get "x64" in the New Platform combo then the x64 C/C++ compilers are not installed. They are not by default (remarkably) unless you started the VS2008 install with the Custom option and turned the option on. Rerun setup.exe to add them, don't forget to rerun the SP1 setup as well. You can double-check by verifying if the vc\bin\amd64 folder is present in the VS install folder, that's the home of the 64-bit build tools.
Another trap exists when the x64 platform already exists in the solution file, brought in by the managed projects. Be sure to untick the "Create new solution platform" checkbox in the dialog.
It's well supported. You just need to add the platform before it appears in drop-down lists:
Build/Configuration Manager
Active Solution Platform
<New...>
x64
If you are using VS 2008 Express, it will not include x64 support.
EDIT: If the configuration already exists on the solution, but not on the project, use this sequence:
Build/Configuration Manager
Go to the line with the project, column Platform
Drop-Down list, <New...>
x64