I wish to install an After Effects plugin on the end-users' system. To ascertain the location of installation, I must find out which version, or versions of After Effects are installed. Because the folder structure looks like this:
HKLM/SOFTWARE/Adobe/After Effects/(version)/key
It's not very simple. Most graphic designers install more than one version of After Effects. And I must present them with all of them in order to let them choose which version they with to install the plugin on.
Conversely, I wish to present the user with three options:
A key that contains the common install path
A key that contains the main install path
A custom path
How's that going to be possible given the abilities and limitations of Inno Setup?
Thanks.
You need to know which version is installed on the end user's PC.
It's a piece of cake. :-)
Look at "HKEY_CLASSES_ROOT.aep": It will rewrite every time the installation is executed. So you know the latest version.
For example, it is 4.0 version when the value of "HKEY_CLASSES_ROOT.aep" is "aftereffects.project.40". And then you can check out "HKEY_CLASSES_ROOT\AfterEffects.Project.40\shell\open\command". There is the installation path.
That's it.
Related
My requirements are as follows:
If an application with version e.g. 12.0 is installed at C:\Folder1 and a setup with version 13.0 is to be installed in the folder C:\Folder1 then the setup of version 13.0 should uninstall 12.0 version silently and install the latest version 13.0
If an application with version e.g. 12.0 is installed at C:\Folder1 and a setup with version 13.0 is to be installed in the folder C:\Folder200 then the setup of version 13.0 should install the latest version and also retain the version 12.0
Things I have tried :
If I use the upgrade code method to uninstall the previous version then the uninstall of previous versions will happen even if the previous version is installed anywhere on the system.
Using custom action - create a vbscript to read the installed products using WindowsInstaller.Products data and using the Product code created a command to uninstall the application using "msiexec.exe /x ProductCode"
This custom action when added in the "Before File Transfer" section in install shield project, gives a pop-up that "The application is installing the version and to wait till it has completed the process".
The "Wait for Action" property for the custom action is set to Yes.
I tried setting it to "No" as well still same pop-up appears.
If I add the custom action in the section of "After setup complete Success Dialog" in install shield project, then both versions are installed and after the vbscript executes, it does uninstall the previous version.
The problem with this approach is, when I double click on the desktop icon of the application; it starts installing and displays pop-up of the progress of installation. This would be confusing for the customer.
So this approach is not suitable.
We have not added any data in registry so cannot use the registry method to uninstall previous versions.
This is a very basic requirement for any software, but I am not able to make out how to achieve this. Please let me know if anybody has some pointers.
I have Installshield limited edition 2015 and Visual Studio 2015 Professional.
This actually is not a "basic requirement for any software." The basics are if a ProductCode/UpgradeCode is installed upgrade it.
For point 2 you're getting the pop-up because you're trying to run 2 MSI ExecuteSequences at the same time. If you'd like to continue down this road you'll have to move your uninstall action to the UISequence. Beware that silent installs will not run this action since it never hits the UISequence. Also, the better way to head down this road is to build your own bootstrapper (setup.exe) that controls the flow of uninstall/install.
You can't do that because an upgrade (a major upgrade) MSI doesn't care where the previous version of the product is installed. An new MSI with an UpgradeCode (and a few other details) will upgrade an existing product that matches, uninstalling that older product wherever it's installed.
Some Issues (not a complete list):
If you want to install another product and NOT upgrade the existing product then you need an MSI that (for example) has a different UpgradeCode or doesn't do a RemoveExistingProducts.
Your MSIs (old and new) need to set ARPINSTALLLOCATION, so you can ask where they are installed. That lets you compare install locations (but IMO not an ideal solution).
There are issues such as whether the two separate installed products now have the same shortcuts in the start menu, whether there are any shared files in common locations, whether there are any non-shareable items (service names, global event names etc).
There are also maintainability issues, such as how to upgrade or patch two almost identical installed products.
Anyway, I would simply ask the user if they want to an upgrade or a side-by-side install, rather than base that decision on a choice of folder (which seems IMO an unusual side effect of choosing an install location).
The general choices are probably based on having a condition on the RemoveExistingProducts action, based on a command line property or other mechanism. Or, depending on maintainability requirements you could change the upgradecode (with a transform on the command line) so that the upgrade doesn't occur. It's not clear to me that detecting the install location of the previous MSI in the browse folder dialog of the new install is straightforward.
I am afraid MSI does not lend itself too well to this sort of scenario - as you have discovered.
Is this a corporate software, or is it for general, large-scale distribution?
What is the purpose of this multi-instancse approach? Does this MSI effectively install two different versions of the same application?
Instance Transforms: I suppose you could investigate the instance transforms concept. It is intended to allow multiple installations, but I dislike the concept and have never used it actively. I am hence not able to give you the inside story of limitations and gotchas - sorry - maybe someone else can illuminate?
As PhilDW states you can use another upgrade code for the newest MSI, and then install side-by-side with the old installation. Beyond what has already been mentioned you would also need to change all component GUIDs for the new package. WiX allows component GUIDs to be auto-generated based on destination path, but not so for Installshield. The instance transform should be possible to use to install side-by-side without changing all component GUIDs - I believe.
App-V: If you are in a corporate setting, and if I had enough experience, I would also recommend that you check out App-V packaging (virtualization). This allows isolation of applications so multiple versions can run side-by-side. But again, I am not the right guy to give you the inside story. I know there are a number of limitations, but can't elaborate with real-world experience.
Setup.exe Launcher: If your application gracefully handles multiple instances without clashing shortcuts and service name etc... (like Phil describes), then you could install all new versions side-by-side and never uninstall older versions by default via the upgrade table. You could then handle the uninstall of previous versions manually in your setup.exe launcher (if any). I suppose you could use the instance transform concept to install new versions, or you could re-create your setup for each new version with all new component GUIDs and product, package and upgrade GUIDs.
Legacy Installscript Project: I suppose you could abandon MSI and use a legacy Installscript project to deploy your application. I would not recommend this since such projects are problematic for reliable remote management and silent running (both for install and uninstall).
Some links for safekeeping:
WiX - Doing a major upgrade on a multi instance install
I want to install an MSI twice
Disable repair mode and upgrades in wix installer
I have a question concerning software updates. Currently I install new releases into a different folder each time. The user is then required to re-enter configuration parameters. This of course is not too optimal. The software is Windows forms and I use the settings. Settings file.
So the question is what happens if I install a newer version into the same folder as a previous install? Will files just get replaced? What about if I have added settings in the new version? Will they be merged?
Anything to watch out for?
Thanks
When the MSIs are related, typically you can only have one instance of it installed at a time. If that's the case, first the earlier version may be uninstalled, so the question is whether the files that store the settings are removed by uninstalling your MSI.
If the MSIs are not related, you can get into a world of pain by overlapping their installations (probably breaking component rules by having two different components describe the same file in the same location, but with a different component code), yet the core question comes down to the same thing: will the updated installation lay down the file that stores the settings.
These are likely the same question, as the easiest way to remove or install a file is by including it in the MSI directly. (There are other ways, but I'm assuming you're not using those yet.) If the file is not part of the installation, nothing will happen to it, and the answer to your question comes down to what your application does when it runs with a settings file created in a different version. If the file is part of the installation, and component rules are not being broken, it will either be uninstalled then freshly installed (wiping any configuration), or per File Versioning Rules and Default File Versioning, the file will either be left untouched or completely replaced with the new version. Windows Installer doesn't know how to merge your settings file.
Thanks for taking the time to answer my question.
So bottom line I should just avoid these issues and install in another folder. I should also make a copy of the settings and put them in my own file which can be used to update my new installation. That would be the safest route I guess.
Thanks
I've been installing programs with chocolatey, but it's not adding them to my path automatically. Does anyone know a solution? I just followed the install instruction on Chocolatey's front page, and everything works well. The programs just aren't being added to the path.
It depends on what you install, and whether those native installers add themselves to the path in some cases.
If the package maintainer doesn't take the extra step in the cases where the installer doesn't add a program folder to the PATH, then those items may not be available on the command line.
The other side of this is that those items may be in PATH, but not to your current shell (cmd/powershell/whatever). This is due to how Windows works versus terminal in *nix. We've made some improvements there but it's not perfect. Expect things to get better over time in that aspect.
We have one issue out for ensuring that we create the User PATH correctly in the registry. This might be what is causing the issue for any items that may be adding themselves to this PATH instead of the system PATH.
We have an installer solution written in Visual Studio 2005 Installer; that calls a C# custom action and we have hit a known issue, regarding the fact that on an upgrade - the old install code is run and not the new code, because Windows is running a cached version of the custom action dll. We know this and although not over the moon about it - we have moved on.
When we release a new version of the installer and a user runs it, we now want it to check to see if an ealier version is installed - if there is one; we want to display a message telling them that they have to remove the old version via Add/Remove Programs. We know if they do a manual uninstall followed by an install, then all is fine and dandy - BUT it doesn't matter how many times we tell our users, via documentation; that this is what they have to do - they will still try and just run the new installer, without removing the old version first.
Therefore, we would like to put up a message and thus force them to to what they are told !! I've seen some installers do this ( though of course not sure what installer package was used to create these ). We only have VS 2005 and of course orca !!
Cheers,
Chris.
This can be done through a custom launch condition:
create a search which determines if the old version is installed (you can search for a component, registry entry or file)
use the search property as a custom launch condition
For example, if the search property is OLD_VERSION, the launch condition can look like this:
Condition: NOT OLD_VERSION
Description: An older version was found. Please uninstall it using "Programs and Features" in Control Panel.
When OLD_VERSION property is set to a value (an older version is found), this launch condition will show the message and stop the install process.
This doesn't quite make sense. Have you remembered to change the package GUID in your new setup? The package GUID identifies a specific setup file, and if two MSI files have identical GUID they will be treated as the same file regardless of whether they are or not. This could trigger a cached version of the MSI to be invoked and all sorts of hell breaks loose.
I would recommend reading up on "major upgrades" which will allow automatic uninstall of the existing version before the new version is installed. You also need to make sure you understand the basics of the technology before deploying to the wild. You must NEVER use identical package GUIDs for any MSI files. It's practically always wrong, and will lead to very mysterious problems.
I can't write up the whole major upgrade solution here, but basically it involves authoring the "Upgrade" table of your MSI to detect versions to uninstall. You need to change the package code, product code and version number (only 3 digits matter) and keep the same upgrade code (two MSI files with the same upgrade code "know" they are related - i.e they are from the same product family). Check MSDN for samples of major upgrades.
NB! If you have deployed MSI files with duplicate package GUIDs to your developer machine, it could have stray installs that must be cleaned up with MSIZap or similar. Use caution, or better yet test your new installer on a clean test system. Developer systems are full of junk and not generally good for MSI testing.
I currently have a project with an installer I made with NSIS, but I would like to have an update to new versions that only has the changed files and will show a changelog. The target platform is windows. What methods/suggestions do you have to do this?
You might want to reconsider using NSIS. If you are into patching and distributing updates you will probably get the most benefit from using an installer technology that utilises the Windows Installer capabilities (msiexec).
NSIS is basically a program that runs and does what you want whereas a Windows Installer type installer forces you to split your application into features and components which can be managed by the windows installer msi service. MSI will track things like what versions of products you have installed, whether running the installer again will run in maintenance mode, whether you are allowed to install 2 products of different versions, whether a patch can be applied to a particular version of a product or any other question relating to updates and installs.
Basically most of the stuff you are requesting will be available out-of-the-box if you change to a Windows Installer technology. Whereas if you use NSIS (which doesn't use Windows Installer technology) then you will have to implement it all yourself.
Just as an example there is a pretty comprehensive installer builder called AdvancedInstaller ( http://www.advancedinstaller.com/ ) that sounds like what you want.
Alternatively, if you want to spend the rest of your life trawling forums and newsgroups then there is an open source product called WiX that does something similar ;)
In spite of my previous comment I have written a 5000 line installer using NSIS with 13 custom pages. I have even looked at patching and it's a bit of a hack. The main bit of advice is to make sure you are patching the version you think you are patching then use one of the patching plugins available.
There are several patching technologies that compare files and produce patch change files and the NSIS code required to "install" them. I have found that NSIS Patch Gen did what I wanted pretty well with the least amount of hassle. The documentation is a bit thin but once you figure it out you think "Oh yeh".
You are probably going to have a little bit of trouble with an automatically generated Change Log. I would suggest that you create the Change Log yourself (or at least add the extra changes to it with each application change you make) and just include it as if it was a normal application file and let the patch generator update it.
http://sourceforge.net/projects/nsispatchgen/
One possible way would be to store an XML file on your download server that has each released version and a list of files that changed for each release. The installer would write a registry key on install of the version of files it installed.
Then, on update, the installer downloads and parses the XML file, and finds any nodes that have higher version numbers than what is currently installed. You display all the files in a text box on an installer page, and when the user confirms, the installer downloads all the files, and then updates the registry to the latest version.
are you familiar with cURL?
http://www.shininglightpro.com/products/Win32OpenSSL.html
http://curl.haxx.se/download.html#openssl
it will download any protocol, and you can use it to download your files. it's a commandline app.
in the installer, schedule a program which should check first to see if the main program is running or not and quit if it is running if not, calls curl to download a batch file from your site with the updates, then runs the batch file.
the batch file it downloads updates the app by downloading the correct files using curl.
the process should run maybe every 2 weeks or once a month, depending on how often you update.
the uninstall part of the installer should be capable of removing all parts of the app in question,including any updates. this can be accomplished by removing all files from that subdir of program files.
RMDir /r /REBOOTOK '$INSTDIR'
RMDir /r /REBOOTOK "$SMPROGRAMS\$StartMenuFolder"
Delete '$SMPROGRAMS\$StartMenuFolder\gpl3license.lnk'
Delete '$SMPROGRAMS\$StartMenuFolder\readme.lnk'
Delete '$SMPROGRAMS\$StartMenuFolder\${PRODUCT_TITLE}.lnk'
DeleteRegKey HKCU "Software\Your major subkey\${PRODUCT_NAME}"
DeleteRegKey HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${PRODUCT_NAME}"
DeleteRegKey /ifempty HKCU "Software\${PRODUCT_NAME}"
PRODUCT_NAME is a !define I made because I use these nsi files like a template.
this is only a piece of the installer file's uninstaller section.
I've been able to create a patch updater program for my Windows app (a CLI which uses NSIS as its installer) by releasing the app to my personal CDN (or some hosting platform) and taking advantage of Node.js modules like path to replace the binary (using a similar procedure to equinox.io) with a given version from the CDN and winreg to update the Windows Registry accordingly. Since I've namespaced my Windows Registry key, the uninstaller still works for it.
If anyone wants more details on this, please ask. I'm happy to help.
Some compilers like Delphi make a lot of changes in the final executable even if you change a little part of your code.
So first you should see if it worth patching.
Another consideration is patching by itself.
Patching maybe blocked by some Anti Virus Software specially in some system folders.
and finally incremental patching data size can grow beyond the original files.
Based on above subjects I don't suggest you patching.
Use full installers instead