I wrote a C# program in Visual Studio that uses the Setup & Deployment Project to create an .msi installer. The "InstallAllUsers" value is set to "True", so it'll install "Everyone" by default, but the users can change it to "Just Me" during setup.
It's just a basic installer - nothing fancy.
My question is this: after they install the program, is there a way to tell which option they chose? Is there a registry key that I can dig for that will tell me whether they chose "Everyone" or "Just Me" during install? I'm not programmatically adding any registry keys, and I can find the "Uninstall" key for my program, but I don't know if there's a value in there that will tell me.
* EDIT *
For a clearer picture:
As I make changes to my program, I increment the version numbers and give the updated .msi to the users, and they just rerun the installer. There was originally only supposed to be a couple of users, so I didn't make a complicated updater. Now there are many users, and the updater is in-the-works. For now, the current users are happy with the process - I give them a new .msi and they run it again - except for one thing: the installer doesn't "remember" their settings from the last time they ran the installer (their words, not mine). I can get the directory of their last install from the "Uninstall" regisrty value and set it with TARGETDIR, so I've got the installation path covered. But I'm trying to figure out if the user changed "Everyone" to "Just Me" the last time around.
One way could be check for current logged in user in registry and see if it has the software listed in in installed software list under HKEY_CURRENT_USER\SOFTWARE\*
There's an example here of enumerating products to find out which context they were installed in. If you know the ProductCode you can just do the MsiGetProductInfo part.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368279(v=vs.85).aspx
There are APIs for this, so it is more advisable than guessing based on what might be in the registry.
The installation folder properties window in Visual Studio setup projects has an InstallAllUsersVisible property you should set to False. Otherwise it's going to be a nightmare when you do an upgrade with RemoveExistingProducts=True because that requires the upgrade to be in the same context as the original install. You'll find people trying to do an upgrade with All users of an installed Just me product and it will not work.
I don't like per-user installs due to all the problems relating to upgrades, patching, etc... Accordingly I managed to migrate per-user installs to a per-machine during a major update install using Installshield and their built-in ISSetAllUsers custom action plus some re-sequencing of various standard actions. The description can be found here: windows Installer - uninstalling previous version when the versions differ in installation policy (per-user, per-machine)
If you want to migrate all installs to a per-machine install, you could replicate this approach using Phils suggestion to read the current installation context via your own custom action and then run this custom action in place of the ISSetAllUsers custom action that Installshield provides. Then you can follow the rest of the procedure from the link above.
Related
I have WPF application who is possible to update when is have new version. For create installer I will use Visual Studio Installer. I understand how to auto update my app, but this is not exactly what I want.
I want when user check is want to "Automatically check for updates" only then is check do is have new updates. Like in the picture
My question is: Is it possible with Visual Studio Installer to manage update for application. When user is checked then if is possible to update to new version. If user not checked then the application is not check for new version.
Im sorry for my bad English. Thanks in advice.
It's not very clear whether you want that checkbox in the installer itself or in the app. All the instances I've seen are in the app. There's no point in putting the check in the installer because the user does that just once, and updates may be generated after the product has been installed. You cannot run the same install again! So this check is added to the app, and the implementations I've built do a web service call to the company web site (passing in the installed product's version, ProductCode, UpgradeCode) and if there is an update the app downloads it. The user may or may not be able to install the upgrade if it requires elevated privilege and the user has limited privileges.
The supported upgrade mechanism with VS setups is to increment the setup project's version property, accept the requested changes, rebuild the entire MSI with incremented file versions for the files you need updating, and set RemovePreviousVersions to true to upgrade the entire product.
How can i install windows installer for 64 bit? I am getting the following error while building the setup file in InstallShield Limited Edition.
As for your errors, they can be caused by something as simple as having the directory open in an explorer window (try closing it a rerun). And have a look at this old IS KB Article
Another possible cause is your Setup PreRequisite file, see this link
"Error appears (in Installshiled 12) if during editing a .prq in Setup Prerequisite Editor select the check-box "Requires Windows Installer engine and/or .NET Framework to be installed first" and after deselect this option. After that in prq-file appears empty section "dependencies", which incorrectly, probably, processed by the builder. It is necessary to remove this section (in any text editor) to avoid an error. "
With regards to your warning:- Have you setup the software id tag ? the following is taken from here Especially read the part I've put in bold.
To include a software identification tag in your installation:
In the View List under Installation Information, click General Information.
In the Software Identification Tag area of the view, modify the values of the settings as needed.
The Use Software Identification Tag setting lets you specify whether you want to include a tag in your installation. Select Yes, which is the default value, and then configure the other settings in the Software Identification Tag area as needed.
When you use tagging in your project, InstallShield adds the tag to two new components that it creates, and it associates the components with one of your project’s features. The components are:
ISO19770_LocalTag, which has a destination of INSTALLDIR
ISO19770_SystemTag, which has a destination of CommonAppDataFolder
Use the Setup Design view if you want to associate these components with a different feature in your project. For more information, see Component-Feature Associations.
At build time, if the following conditions are true, InstallShield includes the software identification tag with the installation that it builds:
Yes, the default value, is selected for the Use Software Identification Tag setting in the General Information view.
The Unique ID, Tag Creator, and Tag Creator ID settings in the General Information view have values.
Note that if tagging is enabled but you have not entered values in one or more of the three aforementioned tag identification settings, InstallShield generates a build warning to inform you that the tag could not be included in your release. To resolve this warning, configure the settings in the Software Identification Tag area of the General Information view as needed.
If you configure your project to include a software identification tag and you also configure the release in the Releases view to use a .pfx file to digitally sign your release, InstallShield digitally signs the tag at build time. Note that the .NET Framework 2.0 or later must be installed on your build machine in order to sign a tag file.
Leaving the stuff below, but looking closer at your screenshot it looks like it's claiming certain files aren't in folders where it's looking... I don't think that has anything to do with installing the file to your system as your system isn't Vista, XP, AND Server 2008 (at least I would assume you aren't running three OS at the same time lol). I could be wrong, but this sounds like an import problem... it looks like it's trying to import those files as files your user needs to install your program... you need to get those 3 installers and then import them (package them, whatever this program you are using does) as prerequisites. That SHOULD solve the problem.
--------------Probably not applicable but if above is incorrect----------
Simple suggestions... unlikely, but my usual troubleshooting steps when all else fails.
Check your file paths.
Double check that you ARE installing the version for 64bit.
Your harddrive isn't full is it?
Turn off virus scanners.
Try installing in safe mode.
Run a virus scan (use something good like Malwarebytes).
Check the Windows error log.
If you downloaded it on a different device try downloading it on the computer you want to install it to.
Download the installer on a different device.
Run as Admin or from a new user account.
Change the folder you are running the installer out of... try running the installer right out of c:\
Install it through Windows Updates (I'm just assuming Win 7 has them, I avoid windows update).
Make sure you have all the .NET frameworks installed (I've seen odd things happen when you don't)
Run the installer on a different computer to make sure it works.
Found this through Google... http://winhlp.com/node/40 the bottom of the page shows some software that can contribute to this error... it may say 'server' but I'm sure that even if the computer isn't networked these can still cause the problem...
I have a .NET 3.5 Setup Package Project which installs my application successfully.
The setup package deploys a number (around 70) custom files for use from within the application.
From time to time I have the requirement of deleting some of these files, however upon restarting the executable, it automatically runs a portion of the Setup MSI again, and re-installs these files.
The only way I can achieve my desired result at the moment is to delete the files after starting the executable.
I have looked through the attributes on the files in the setup package such as Vital and PackageAs, however cannot seem to identify the required setting to achieve this.
Does anybody have any idea what is needed to acheive this ?
Much thanks
From http://msdn.microsoft.com/en-us/library/kz0ke5xt%28v=VS.100%29.aspx
"
How do I turn off repair for a file that users are expected to modify or delete?
Visual Studio creates advertised shortcuts so that when the program is started it verifies that all its files exist. To change this behavior and cause it not to repair the file, select the files in the setup project and change the Condition property to NOT REINSTALL so that the file will not get reinstalled on a repair and its Transitive property to TRUE so that the condition is re-evaluated. This will cause the Installer to flash on the screen the first time after the file is deleted, as it verifies that the file should not be reinstalled, but you will not see the installer after that.
"
This has annoyed me too, and I don't know the specific setting you have to change to prevent this, but I can tell you a work-around that I've used. I found that it only happens when I run the application from the shortcut that was installed as part of the installation. So, if you create a new shortcut to the application and run it via that shortcut, then the files you've deleted won't be automatically restored.
Windows Installer supports three types of product upgrades: major upgrades, minor upgrades, and small updates. A synopsis of which upgrade to use under what circumstances can be found here: http://helpnet.flexerasoftware.com/robo/projects/installshield12helplib/MajorMinorSmall.htm
What you want to do is set you installer up in such a way that the new version of your software sees the file deletions as upgrades to a prior version. If you fail to do this and then you delete files, the program installation thinks it is damaged, and tries to restore the files you deleted when the program is executed again.
In InstallShield (the installer product with which I am familiar), there is a Product GUID and an Upgrade GUID. The Upgrade GUID always stays the same within your product family of different versions. The Product GUID changes with each new MAJOR or MINOR release. In general, if you follow this pattern, and then specify file deletions in your new version, the installer should interpret the file deletions as upgrades, and you should not get any errors on subsequent execution of the newly-installed version.
I have a Windows service written in C# using VS2005.
The installation is via a wizard that calls msiexec to install the msi file also created using VS2005.
I am having trouble generating an msi file that will upgrade from one version of the service to another. The wizard program handles detection of the currently installed version, stopping the service, coming up with an appropriate command-line for msiexec and then re-starting the service.
The existing msi has a version property of 1.1.02, the new one is 1.1.03. The product and upgrade codes are identical.
Uninstalling 1.1.02 manually via add/remove programs works fine, as does installing 1.1.03 onto a "clean" system.
Upgrading 1.1.02 to 1.1.03 goes through the motions but the end result is 1.1.02 installed.
The command line that the wizard uses for upgrading is:
msiexec /qb /i "MyProduct.msi" REINSTALL="ALL" REINSTALLMODE="vos"
Where am I going wrong? I'm assuming I must have missed something fairly fundamental...
The fall-back position is to inform customers that they need to manually uninstall 1.1.02 before running the wizard to install 1.1.03 but I'd rather not have to do that.
Edited to add:
Changing the product code (as VS2005 also prompts you to) actually removes the ability to upgrade at all, as it the installer won't let you do a reinstall if that product code hasn't previously been installed.
All it will then let you do is install (and then you get the usual "service already exists" -type message).
There are several things that need to be done to get "upgrades" to work with MSI's if you want to automatically remove the previous version.
First some background information about the mysterious "codes". There are 3 codes (GUID's) associated with an MSI:
Package Code - This identifies a particular version of the MSI installer and should never be reused across builds. It must always be updated.
Product Code - This identifier is used to ID a particular version of the application. It is up to the installer author to decide when to assign a new product code.
Upgrade Code - This identifies the application and should not change through it's lifetime
The Upgrade Code should never change. For you upgrade scenerio, the Product Code must be changed for each version. Additionally, as you mentioned, you must bump the version number. The Product Code and Upgrade Code can be found by selecting your setup project and going to the Properties Window. The Package Code is hidden in Studio and will always be updated.
The item you are probably missing, is that you also need to set the RemovePreviousVersions setting in the Properties Window to true.
One more thing in addition to mohlsen's answer (For Visual Studio 2008):
In order for your Primary Output (your EXE!) to upgrade properly, you must increment the FILE VERSION
This setting can be found in the Project Properties: Application Tab -> Assembly Information
An easier way to manage this is to REMOVE the AssemblyFileVersion from all assemblies, including the main executable and all the managed DLLs.
In each of your AssemblyInfo.cs files, I recommend doing something like this if you don't care about the version numbers, but want to have some traceability.
[assembly: AssemblyVersion("1.1.*")]
// don't need this [assembly: AssemblyFileVersion("1.0.0.0")]
Everything still compiles fine, and if you don't have the AssemblyFileVersion defined, then the installer assumes that everything is different every time (which is probably fine if you are installing all of the DLLs next to the main EXE).
I spent a long time figuring this out, especially if I don't want to have to increment anything manually!
I want to check if an app is alredy installed through launch conditions.If yes i want to exit the installer,if no the installation should continue.Could anyone tell how to achive this in c# installer?.
Regards,
Harsh Suman
I'm not sure on how to do this specifically with C#, but while using the Nullsoft Installer this is the approach I've seen used: before installing, check for a registry key that is created during the install.
Uninstallers show up in the Add/Remove Programs control panel. The list of the uninstallers is stored under HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall. If the installer registers an uninstaller, the uninstaller's key is a good key for the installer to check for, because:
Assuming the program is being installed for all users, the key tested for must be under HKey Local Machine (HKLM) not a key specific to the current user (HKey Current User). The uninstaller's key is under HKLM
Sometimes multiple versions of the same program need to be installed side-by-side. Uninstaller keys should be specific to each version, so rules can be added to check the installer's version number against installed versions.
There is a limitation with checking for registry keys to tell if a program is installed: if the program is deleted out of Program Files by hand (without using the uninstaller), reinstalling will fail. To avoid this problem, after finding the uninstaller registry key, the installer can check that the uninstaller program still exists. If it does, it's probably safe to assume the program is still installed.
While playing with installers and conditional installation, it's worth keeping in mind that sometimes reinstalling is useful for cleaning up problems. It can be tedious to be forced to walk through a (troublesome) uninstall to be able to reinstall.
See NSIS's page on Add/Remove Programs for more details on uninstall registry keys.
Put an entry in the registry on install. If, when the installer runs, the entry is there, then the program is already installed (or your user has hacked the registry to make the installer think it has been). If it's not, then you haven't installed it yet.
If you don't want to put anything in the registry (due to admin rights or anything like that), you can simply check to see if the folders or files you install are present. Yes, this assumes you install to the same folder every time, but it's an option.