What is the most reliable way to check for firefox installation? - firefox

I am making a software that comes bundled with a firefox extension. In my instalation script I want to prompt a user weather he wants to install the extension. But for that I need:
A way to tell if firefox is installed or not
A way to tell which version of firefox is installed
How would I do these two things in InnoSetup or C#? I tried manually checking the path to default firefox install dir or checking for uninstall records in registry. I think that these methods are not reliable at all.

The recommended way is checking whether HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox registry key exists. There will be a subkey for each installed version. If you are paranoid, you can also check the value HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\<version>\Main\PathToExe - if that file exists then Firefox is really installed and you aren't looking at a stale registry key.
Note that you can only detect a Firefox installation only if the installer was actually used. You can always "install" Firefox manually, simply by unpacking the setup executable with 7zip - into any directory. Nightly builds are also available as regular zip files that are easier to unpack. This will work just fine but won't add any registry keys that will allow you to find this installation.

Here is a shortened list of created keys (by Firefox 27.0.1 installation)
HKLM\SOFTWARE\Classes\FirefoxHTML\
HKLM\SOFTWARE\Classes\FirefoxURL\
HKLM\SOFTWARE\Clients\StartMenuInternet\FIREFOX.EXE\
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe\
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe\Path
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox 27.0.1 (x86 en-US)\
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe\
HKLM\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\27.0.1 (en-US)\
HKLM\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox 27.0.1\
HKLM\SOFTWARE\Wow6432Node\Clients\StartMenuInternet\FIREFOX.EXE\
One of our client did not have the "Uninstall" one so we'll use another from that list.
I am going to use: "firefox is installed when at least one of the following keys exists:"
HKLM\SOFTWARE\Mozilla\Mozilla Firefox\
HKLM\SOFTWARE\Clients\StartMenuInternet\FIREFOX.EXE\
HKLM\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\
HKLM\SOFTWARE\Wow6432Node\Clients\StartMenuInternet\FIREFOX.EXE\

I think HKLM\SOFTWARE\Clients\StartMenuInternet\FIREFOX.EXE key isn't dependent from OS bits, so I suggest this.

Related

How to find the name of a HKLM subfolder using Inno Setup?

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.

Detecting if Adobe Acrobat 9.3+ is already installed

I am using .NET Installer as a bootstrapper and I need to detect if Adobe Acrobat 9.3 or above is installed as a prerequisite.
Currently I am using this registry to detect the installation:
HKEY_CURRENT_USER\SOFTWARE\Adobe\Acrobat Reader\9.0\AdobeViewer\ELUA
I simply check to see if the key exists. This has the following problems:
It depends on a registry path that will likely change with newer versions
The ELUA key only exists after adobe reader is launched. If the install is run again before reader is ever launched it forces them to re-install
This key does not allow me to really check what version of adobe they have.
FYI, .net Installer can check for existing products by file {exists / file version} or registry key {exists / version}. I prefer to use the registry as applications can be installed anywhere and I cannot scan the "Uninstall" registry keys using this tool.
Any ideas?
http://dotnetinstaller.codeplex.com/
Under the key
KEY_CURRENT_USER\SOFTWARE\Adobe\Acrobat Reader\9.0\Installer
you can find the install path. Once you have the install path, you can go there, find the executable "AcroRd32.exe" and get its version with the code
FileVersionInfo myFI = FileVersionInfo.GetVersionInfo("yourexe.exe");
As you said, never versions may have different registry keys. You will have to handle that in your code whereby you go through the keys under 'AcrobatReader', get their names, which may be '10.0' and '9.0', parse them, and then compare them to get the newest version info.

FireFox API install extension

How do I install, update, uninstall FireFox extensions on Windows?
The article (https://developer.mozilla.org/en/Adding_Extensions_using_the_Windows_Registry) seems like a legacy information...
I have installed FireFox 3.6.3.
However, I don't see "HKEY_LOCAL_MACHINE\Software\Mozilla\Firefox\Extensions" in my registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla]
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox]
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\3.6.3 (en-GB)]
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\3.6.3 (en-GB)\Main]
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\3.6.3 (en-GB)\Uninstall]
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox 3.6.3]
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox 3.6.3\bin]
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox 3.6.3\extensions]
For example, I want to install my_ext.xpi (ID: my_ext#my_site.com, Path: c:\myapp\ff_addons\my_ext.xpi).
Could you talk me how can I install my extension ?
Which firefox's versions support this method ?
The extension registry key (HKEY_LOCAL_MACHINE\Software\Mozilla\Firefox\Extensions) doesn't exist by default - simply create it and register your extension there as detailed in Mozilla's instructions (which you linked to).
This method has been working fine for me for over a year now.
You also have another option (which also works on non-Windows machines): Installing Extensions
The windows registry method is not a legacy method, and it's the supported way of installing an add-on for all users on a machine (and all Firefox profiles).
I'm curious as to why you felt it was a legacy method.
Are you talking about an extension or a plug-in?
Extensions are generally installed by having Firefox open an .xpi file. And .xpi files are just .zip files with a manifest (.rdf) and your various scripts and libraries. You can install it manually by creating the right directory structure. On my machine extensions live here: C:\Users\[username]\AppData\Roaming\Mozilla\Firefox\Profiles\[random-number].default\extensions. You create a subdirectory there called yourextension#yourcompany.com and then unzip the contents of your XPI inside the subdirectory. The next time the user re-starts firefox, your extension will be installed. There are a few gotcha's though:
Users have to manually restart Firefox.
You don't know which profile to use if there is more than one. The profile is identified by the [random-number] above. Many users have more than one profile.
On Mac and Linux this is a different directory, though the same basic idea applies.
Plugins are things like Flash that run inside a webpage. You can install those by setting a registry key, but I think in general there is a well-known folder where Firefox looks and loads anything that starts with NP (e.g. NPSWF32.dll). Seriously, it looks for NP. And each plugin must export certain NPAPI functions that Firefox uses to negotiate... stuff.

Uninstall an MSI with msiexec fails with new version of MSI

We are installing several web sites using msi's as part of continuos integration tests.
For each build we want to uninstall the old msi and install a new one.
Problem is we do not have the old msi after the build server has done a get latest and rebuilt the system.
Is there a way in which we can uninstall the msi without having access to the orginal msi?
Yes you can, if you know the product code. Just type
msiexec /x [ProductCode]
on the command line. Or you could do it through the Add/Remove programs applet.
If you want to find the physical file, Windows actually stores a copy of the msi when it runs it - you will find it somewhere in your %WINDOWS%\Installer folder, but it will have been given a random name so could be quite hard to find :)
Alternatively if you don't know the product code (which you should) then try searching for your app name under the HKEY_CURRENT_USER\Software\Microsoft\Installer and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData registry keys, you will find the product code there. (quick hint: you can also search for UninstallString values in the registry).

How do you make an update installer with NSIS?

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

Resources