In a .wxs file I have:
<Environment Name="PATH" ... Value="%APPDATA%\Python\Scripts" system="no"/>
Unfortunately this does not seem to work. After installing the installer on another machine, I do see that '%APPDATA%\Python\Scripts' is contained in the PATH environment variable. But typing 'foo' (where foo.exe exists in that set path) prints command not found.
What exactly went wrong here? Is there a way to fix this?
This looks like a bug in Microsoft Windows:
http://support.microsoft.com/kb/329308
Yet, there is no workaround from the WiX side.
I don't think the cmd.exe gets updated unless you recycle them. I've also seen the environment get stuck until logoff. Seems to be more of a Windows behavior than anything else. The Windows Installer does send the message to say the environment was updated... I just haven't seen it work all the time.
If you're updating environment variables and want them available immediately for your applications, then best solution here is to use ScheduleReboot element to prompt the user to restart post-install.
It seems like a bit of overkill just to update an environment variable, but it will do the trick.
Related
I have made an installer, a Visual Studio SetupProject, which installs a software I developed and checks if a certain program is installed on the target machine. If not, it launches its original installation file. This file is copied to the target machine during the installation and is launched throughout a CUSTOM ACTION.
Everything goes well with the installation but I have only one problem:
The separate installer, which I didn't develop, should append a PATH to the User Environment Variables referring to the path of a BIN folder in its own installation folder. It doesn't! I checked the PATH registry value of the User Environment Variables and it really doesn't get updated.
However when I install the program separately everything goes well!
I tried to to change the PackageAs Property of the attached installation file from vsdpaDefault to vsdpaLoose in order to make the operation, probably, a bit more "separate" sort of say but it didn't change anything.
Why do the Environment Variables not get updated? My guess is that my installer doesn't have some kind of rights necessary to change these variables.
BTW I'm using Visual Studio 2010.
I believe Hans has the answer. If you fire off that setup from yours as a custom action then it runs with the local system account. That means it is not running as the current interactive user therefore it cannot update the current user's path because it's not running as the current user.
This setup by definition cannot be an MSI-based install because it would fail - you can't do recursive MSI installs - therefore it is code based and depends on running in the interactive user's context.
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
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.
http://www.ee99ee.com/blog/2009/02/08/how-to-get-aspnet-mvc-working-under-iis-51-on-windows-xp/
Can the following be put into batch commands? If not, is there an alternative where the configuration can be set through an executable without the user having to configure through IIS?
the simplest solution is to include .aspx into the controller name. so the controller is in the following format
{controller}.aspx/{action}/{id}.
You might be able to set those properties with the GET and SET commands of the Adsutil.vbs script (which works with IIS 5.1, would probably be in the directory C:\Inetpub\AdminScripts\).
I tried a little poking around, and couldn't figure out which keys were needed. But you might be able to figure them out using the Metabase Explorer (from the IIS 6.0 ResKit, or here is a third-party version which I haven't tried).
I have been researching this topic as well and first of all I don't agree with the votes down moderators for a perfectly valid question with research done by the asker. Second the answer is no you cannot put IIS commands in a executable the whole point of IIS is that you set it up once and you are done so just set it up correctly the first time and you should be good also that tutorial you are looking at is rubbish. Just my 2 cents!
I have a very simple application installer that needs to add an action to the shell menu of all files (HKCR*\shell), and I've run into a brick wall: how do I insert the installed path of the application into a registry value? I've tried everything I can think of:
[Path]
[ApplicationFolder]
[ApplicationPath]
[InstallPath]
[InstallRoot]
[InstallFolder]
[InstallTarget]
[TargetPath]
I even tried adding one that I know works in other places ([Manufacturer]) to make sure that the bracket-values syntax actually works in the Registry (it does).
Anyone know, or at the least, have any ideas that I haven't tried?
The one you are looking for is [TARGETDIR]