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.
Related
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.
I have a 32-bit legacy application that allows users to specify the install path as part of the setup (pretty normal stuff...). I also have a custom action defined that runs a silent background install of another required bit of software after the initial installation is complete.
All is well when users install to the 32-bit Program Files (x86) directory.
Where I am running into problems is when users specify the 64-bit installation directory, Windows automagically changes the install path in the background to use the (x86) Program Files folder, which is fine, except that my custom actions that use the same INSTALLDIR property after the initial install is finished still think that it should be the 64-bit "Program Files" path - so the install fails when the custom action can't find the EXE file it's looking for.
My program is essentially exactly the same as the one described here by another developer but never resolved in that forum: http://community.flexerasoftware.com/archive/index.php?t-216268.html
Does anyone have a clue what a valid workaround for this is? It seems pretty basic that an installer should not fail just because users think they should install to "C:\Program Files\Appname" instead of "C:\Program Files (x86)\AppName".
I did peruse the similar questions on here but I don't see anyone else with this issue using custom actions.
In my experience you need to change to a 64 bit template to install to program files. General information in the tree > Template summary > change to x64;1033. At least one file needs to be marked as 64 bit in each directory. It is a check box on the component property. Be sure to check your custom actions still obey run conditions on major upgrades. I am having issues with that currently. Major upgrades on mine is set to remove all and it runs all custom actions no matter the conditions on the removal portion of the script.
I have an installer from a third party. Through trial and error I discovered it was an innosetup installer. When I call it with the /silent flag it installs just fine, until it executes installers for 3 dependencies (direct X is one, for example) which then require user input to cancel. I want to be able to run the installer and have it either install the dependencies silently or not at all. When going through the installer GUI normally it does give me 3 checkboxes at the end on the last page of the wizard (before I would hit the Finish button) that allows me to choose whether or not to install the dependencies. Is there a way of doing this that I don't know about? From my research it seems impossible without knowing the types and components available (and executing the installer with the /help or /? options had no effect) and I will probably need to get a new installer from the third party. The only other option I can think of would be to have some sort of timeout that after a certain period of time of inactivity from the installer I kill the install process (since the files I was interested in had already been installed at that point I think).
Checkboxes on the finish page sound like postinstall [Run] entries. There is no way to influence the selection of these from the command line, except that the original setup author can choose to have a different set of options selected for interactive install vs. silent install. (Or they might have extended the /LOADINF option to work with these, although this is unlikely.)
Given that this is a third-party installer, your best bet is to contact the original vendor and see if you can get them to change the default silent selection, or to add an additional command-line parameter to change the defaults.
Failing that, you could consider using a program such as AutoIt to auto-click the wizard GUI when run non-silently.
(If the things that it's trying to install really are dependencies, though, then you probably should let it install them. And it should be installing those silently too anyway.)
Killing the install process after a specified time seems like an excellent recipe for disaster.
Those are probably [Tasks] within InnoSetup's install, which you may be able to deselect by passing /tasks="" in the command line (along with the /silent). Here is a list of command line options: http://www.jrsoftware.org/ishelp/topic_setupcmdline.htm . Adding /suppressmsgboxes may help also.
It seems it is impossible to do what I wish without knowing more about the structure of their setup. I was however successful in solving my original problem by killing the third party installer after waiting a specified amount of time (which I got from reading this question).
Is it possible to install the entire database(postgresql8.2) via command prompt or batch file or registry file bypassing the trivial procedure for installation. But then to a question comes that, how can we supply default parameters such as name,password,language,default location of database? Currently I'm working on 'Windows XP' platform.
Thank you.
For 8.3 and lower the obvious answer is: http://pginstaller.projects.pgfoundry.org/ which supports or supported silent installations. For more recent versions, please read: http://forums.enterprisedb.com/posts/list/2135.page
Use of existing installers would simplify your life and be where I would start.
This being said there is no reason you can't generate a script to register dll's properly run initdb, etc. This will take some extra knowledge of both PostgreSQL and Windows, and will be mostly suitable for custom solutions (i.e. not cases where you merely are packaging software that runs with PostgreSQL). I don't think an complete answer can be given here because once you need such a solution you need to design your installation around if. Books could be written on that topic. The docs http://www.postgresql.org/docs/9.0/static/install-windows.html should get you started however since the only difference really between installing from source and installing from the precompiled source is just that you need to compile the source files first.
Failing that you could take a look at the binary zip packages. Typically these can be extracted and PostgreSQL can be run from inside them.
I've got an MSI based install that I've wrapped in an EXE file as per my installation packaging software (which is Wise Package Studio 7.0 SP2).
I've made many changes to the install, and every time I've tested them, they've worked just fine... up until now.
I changed some text on a dialog box for when the installation finishes and now it seems that no matter how/where I run the installation from, it won't take my "new" version. It continues to "think" it's already installed and even shows an older iteration of my dialog text at then end of the removal/repair/modify.
It's almost like it's cached that MSI/EXE somewhere and instead of running the one I've recompiled (and fixed the message/made changes) it continues to run the "old" one from somewhere.
Any idea what to check for/what could be going on here? Is there windows folder I need to go check? I'm on XP SP2.
Try running on a different machine, this will definitely rule out any local caching.
Check that the changes you have made are actually in the MSI. (use Orca to do this.)
Okay, so I tried this using an XP VM and taking a snapshot before installing. Looks like somehow the previous install was corrupt and was somehow caching itself on the original test computer I was working with.
By going to a clean and fresh PC, my changes were there and the script worked as expected. Now, I don't know what happened to cause the installation to cache like that somewhere on the PC, but at least I found a resolution.
I'll update this question with the location of the cached files if I can track them down...
To remove any cached Windows Installer information, you can use MSIZAP. My guess is that you haven't changed the package code so windows sees it as the same version of the installer (I'm not sure about WISE, but InstallShield is usually configured to automatically change the package code each time you rebuild.)
As far as the location of the cached files, this is configurable so have a hunt around in WISE and you should find it.