I am new to creating installers. Before used the Microsoft visual studio deployment package. Now trying inno setup, pretty awesome.
I saw that Visual studio one wrote some registries when installed.
Do I have to create Registries for my package too? I have a visual c# application and need to create a installer for my company. Main intention is to create a installer that will easily update the old one, but this is a first version of software we are going to release to customers. Much appreciated. I saw tutorials of Registry in internet, but the point of creating is the one that I don't understand.
I'm not sure what you are asking exactly. If you mean how do I write to the Windows Registry, you create a [Registry] section in your inno-setup file and add what you need. Here is a link to the documentation.
You don't HAVE to write any registry entries unless your app requires them.
Inno automatically creates the usual entries to allow uninstall from the Add/Remove programs applet.
Inno will also automatically handle upgrades with no special effort.
If you have previously distributed the app using an MSI package, then you will either need to allow side by side installs (different folders, etc) or uninstall the previous version first. The article above has a sample of how to get the uninstall path.
Related
I would like to run one installer for three programs, i.e. Folder is created under the name KAM Package, and there are three separate folders with three separate programs and their files. They must also be separately in the start menu.
Welcome to Stackoverflow: Please try to elaborate your questions and make them as specific as possible so we don't end up writing stuff that doesn't help or answer anything of what you really intended to ask about (happens more often than we'd like).
Deployment Tools: As others have said, please choose a deployment tool first. I'll just link to a previous answer to see if it helps you: How to create windows installer (links to Windows Installer tools and legacy setup tools - please do have a look).
Free MSI Tools: And there are free tools you can use to inspect compiled MSI files: Orca, InstEd or SuperOrca (towards bottom). These are not full-fledged tools to create MSI files, but they work great as viewers and for small hotfixes and changes, etc...
Some Links:
Wrap C# application in .msi installer
Windows service NOT shown in add remove programs under control panel
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
I am trying to migrate from InstallShield to Inno Setup. I have all setup but I got stuck on a single case when the user might downgrade from Inno Setup back to the InstallShield. I need InstallShield to fail the installation or at least warn the user to uninstall Inno Setup version first manually (otherwise I get two versions installed and things get messed up).
I CAN´T of course change the existing InstallShield installers in any way since they have already been released. Solution must come from Inno Setup. Any ideas how this could be done? I understand this might me impossible.
A stock InstallShield template automatically authors a prevent downgrade rule into the MSI. Assuming your InnoSetup project was created using the same UpgradeCode as the InstallShield project this should work automatically.
If you gave your new InnoSetup project a new UpgradeCode GUID and authored a remove legacy product type rule using the old GUI in the Upgrade table there really isn't much InstallShield could possibly do. That's the nature of installers... once it's shipped it's shipped.
I do not think this can be done. The Inno Setup does not use the Windows Installer, so the InstallShield won't even know that your product is already installed. And Inno Setup uninstaller cannot know that the InstallShield installer is starting.
The best what you can do is to have your Inno Setup installer remove the InstallShield installation and install itself to another folder. So when you re-install the InstallShield installation, it at least won't conflict/break the Inno Setup installation. And user will be able to correctly uninstall the new Inno Setup installation, if needed.
OK I solved it. (kind of)
There is a simple trick what you can do to trick the InstallShield to think it is already installed even if it is not.
First you need to locate all the registry entries with your UpgradeCode and ProductCode (it should be 3 entries for the UC and 5 for the PC) normally created by the InstallShield. Also note that both GUIDS are stored in the registry in reversed form (first 8 chars are backwards!!! - rest I am not sure of but it can be googled).
Now you need to make the InnoSetup recreate this registry entries. When InstallShield starts it looks for existing version in the registry, if it finds one it tries to uninstall it using the copy of the original installer - path to the copy is stored in the registry at
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products{reversed guid of product code}\InstallProperties]
"LocalPackage"="C:\Windows\Installer\[random string].msi"
If InstallShield wont find this file it will fail. You can also create your own MSI file which will call the uninstall.exe file from InnoSetup.
I have created an MSI installscript project in Installshield. I went to Project Assistant>Application Files, then added the application files(package) and built Setup.exe to install.
After installed these files, I went back to Project Assistant and added some application files, then i changed the product version for updating. Finally, i built the Setup.exe again. When i run the Setup.exe, the automatic update (Upgrade Window Installer Setup) asked me to update a new version. After finishing, I checked Program Files(x86) and the updating didn't do anything, the old package was still here.
How can i update my new package? Is there any way to disable the Upgrade Window Installer Setup?
Thanks for the help.
In my humble opinion, most likely, you added new files to existing Component with keypath, which didn't change. Also you should check "Add\Remove Programs" snap-in in Control Panel to see if upgrade was applied - there should change version of your product.
So, I recommend you check Components, and re-allocate files to new Components if I had right. Also please read more about Components and Files. Could start from here.
Two words about InstallScript MSI project. From InstallShield documentation: Because this project type uses two different engines, it is more complex than pure InstallScript or Basic MSI installation projects. It is recommended only for advanced users.
So, if possible, use Basic MSI project - it's a bit simpler than InstallScript MSI for begginers.
I have an old VB6 application that is deployed using a very old 16 bit version of InstallShield. I have created a new installer with Inno Setup to be 64 bit friendly for my VB6 application with updates.
All of my users already have the existing InstallShield version installed. Currently, I have Inno Setup working. The problem is, I do not want to overwrite the old InstallShield installation files, so my Inno Setup installs to another directory. This causes problems because now I have two versions installed, with two separate icons.
I need a way to invoke the uninstaller of the old InstallShield application when I install the new Inno Setup version. How do I call the uninstaller from the Windows Add/remove programs through Inno Setup? If i reuse the app id for the InstallShield version to be the same as the Inno Setup, and then manually delete the old files, would that work?
You would have to locate the InstallShield uninstall registry key which will reside under either HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ or HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ and then execute its UninstallString value. Once that is done, delete the registry key: it is not possible to reuse the same key with Inno Setup since it will always append _is1 to your AppId to generate the uninstall registry key name. Additionally on older Windows versions it may also truncate this key name and append a checksum, because of length limitations.
Do all this from a PrepareToInstall event function.
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.