I am using the file associations feature in install4j to associate files of a given extension to a launcher.
This is not working when I install on Windows 8.
The associations work properly on other OS versions (Mac OSX, Windows 7, etc), but not on Windows 8.
Make sure that the "Create a file association" actions are after the "Install files" actions, otherwise they will not work if you perform a clean installation (not an update installation).
Related
Some people are having trouble installing my AIR app. Most are installing it fine.
Some of the people having trouble are installing it for the first time, others as an update.
I've tried two versions of the installer - one with a migrated cert, the other without migration.
Also, I've gone through these steps with them:
check that your computer's system clock is correct. Correct the date and time if it not current.
make sure you have the latest updates for your machine eg latest Windows updates for Windows machines
install the latest version of the Adobe AIR runtime (download from http://get.adobe.com/air)
uninstall my app if it is already installed
make sure the application folder does not exist (in, for example, c:\Program Files or c:\Program Files (x86)). If it does exist, delete it.
empty the Trash (Mac OS) or Recycle Bin (Windows)
try installing my app again
I'm wondering if there are any other steps that you are aware of to test?
Cheers
i have a problem with the installation of a Firebreath plugin on Windows XP machine.
I'm using Visual Studio 2008 setup project to place generated plugin dll in program folder to get the plugin work but when i run the installer the plugin is usable only by the user who install the plugin and if i log in the machine with another user with limited privileges Firefox cannot see the plugin.
What i'm doing wrong with this process?
Should i use Wix installer instead of Visual studio 2008 setup project to get the plugin work for all users in the machine ?
What is the correct "Firebreath" way to install a plugin and to make it visible to all users in the machine?
Thank for your time!
Francesco.
1) Nothing. This is as designed; FireBreath installs per-user by default, always has. This is a feature, since it means you don't have to have administrator privileges to install.
2) Not by default, no.
3) Uncomment the following line in your PluginConfig.cmake file and rerun the prep script:
# If you want to register per-machine on Windows, uncomment this line
set (FB_ATLREG_MACHINEWIDE 1)
In install4j, can you include both 32 and 64 bit versions of an application in one install package and let the user decide which to install if the OS is 64-bit? Would the easiest/best solution be to create three projects? i.e. one parent/two children? I'm hesitant to do this because the majority of the included files are not architecture-specific and I'd like to keep everything in one project.
I'm also not tied to install4j if another installer can accomplish this, especially WiX, which is used by other groups in our company.
Currently install4j cannot create a single media file for 32-bit and 64-bit. Since the 32-bit media file works on 64-bit Windows as well, this is usually not a big problem. Common 32-bit/64-bit media files may be implemented for install4j 6.
In any case, you do not need separate projects for 32-bit and 64-bit installers. You just add two media files in the "Media" step of the install4j IDE, one for the 32-bit installer and another one for the 64-bit installer, with different settings on the "32-bit or 64-bit" step of the media wizard.
As for platform specific files, just add two file sets and exclude them as appropriate in the "Customize project defaults->Exclude files" step of the media wizard.
So we've got this 32-bit software package that is installed on both Win XP and Win 7 machines.
The current issue that I'm looking at is that when installing part of the package, registry values are written to add an executable in the package to the windows context menu. These registry values are part of a wix fragment that is generated by heat from a dll that is part of the process (ie. a dll of the executable).
The problem is that while it works on windows xp embedded, on windows 7, not only does the application NOT show up in the context menu, it also breaks something so that the "New Folder" option is removed from all context menus. Uninstalling the application doesn't work, but it can be fixed by adding the registry settings from this site: http://social.technet.microsoft.com/Forums/en-IE/w7itprogeneral/thread/97de8a2a-12f2-4381-a409-a78f4ae551cf
Of course when you install a new build, then it gets wiped away again, and as developers, sometimes we're installing and uninstalling 5-6 builds a day. I've confirmed that it is those particular registry settings by removing them from the installer and building and installing it, and the "New Folder" option happily stays where it is.
So my question is: is there a problem with heat generating valid registry values to write for a 32-bit application/dll to be added to the context menu on windows 7? (for complete disclosure, I'm using win7 64-bit, but we've had the same issue on win7 32-bit, but we haven't tried vista)
Heat simply captures the registry keys written during the DllRegisterServer() call. If you are not getting the registry keys you expect, then look at the DllRegisterServer() code to see what it is doing. Also, you may find it more useful to capture the registry keys once, verify they are correct then not use heat.exe any longer.
That's my preferred approach.
I am trying to create a .msi database using Wix to install a driver package.
Now this driver package is made to run on all platforms and can be installed on any platform (any version of windows, 2k and later, x86 or x64) by right clicking on the .inf file and selecting the "Install" option. Because the package doesn't need multiple versions for different platforms out there, I want to create a single msi file for all platforms.
All went fine until I hit this bottleneck: I am suppose to link with either dfxapp_x86.wixlib or dfxapp_x64.wixlib depending on the platform I wish to install on. This will lead to having two different installers, one for each platform, which I don't want. Including both library files won't work, since they link with dlls that contain the same symbols.
What can I do to have a single installation package for all platforms in this case?
Thanks.
Neither MSI nor DIfxApp support a single package for multiple platforms. You need one per platform.