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.
Related
I have packaged a C# application using VSI_bundle.exe, and when it is installed on some PC's, the following message appears when trying to run the application.
Windows Installer >>>
"Please wait while Windows configures (Product Name)"
The application will then run fine, but when I turn it off and back on again, I get the same situation again. How can I fix this?
The message dialog means that the installed product is being repaired because it's damaged, not the same as when first installed. The Windows Event Log (Application) will have an MsiInstaller entry saying something about the ProductCode and the component that is missing.
It's a feature of Windows Installer that it repairs installed items that get removed, so if the application changes or removes files or registry entries then Windows will want to reinstall them. It's the same as going to Programs&Features and doing a Repair on the product.
Fixing it depends on why it's repairing. For example, is the app deleting files or registry entries, and if so then why?
Sometimes people install the MSI with DISABLEADVTSHORTCUTS set to 1 to prevent the shortcuts from doing the repair, but that cannot prevent all repairs, and may be disguising the fact that the app is removing required files.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368297(v=vs.85).aspx
As others have pointed out, this seems to be a Windows Installer self-repair or "resiliency" issue.
Launching your application via an "advertised shortcut" (good Symantec article on the topic linked) will trigger a key path check for your MSI to determine if your product is properly installed. During this process a discrepancy is found, and a self-repair is triggered to install what is missing.
In certain cases the discrepancy can not be resolved by the self-repair, and it then keeps repeating in vain. Essentially you need to determine what component causes the discrepancy and hence triggers the repair.
Perhaps you can try Stefan Kruger's msifaq first, it is terse and to the point: Windows Installer launches unexpectedly, for no obvious reason.
I have written about self-repair too many times, one of the shorter answers might be this one: Why does the MSI installer reconfigure if I delete a file?
For future reference I include some links on the topic of Windows Installer self-repair or "resiliency":
Comprehensive explanation of self-repair, verbose and comprehensive: How can I determine what causes repeated Windows Installer self-repair?
Solution focused description of self-repair, attempting to find real-world solutions: What do I do when launching an application triggers repeating, endless Windows Installer self-repair?
Self-repair issues for developers, avoiding the problem in the first place: How do I avoid triggering MSI self-repair with my WiX / MSI package? (perhaps try this one too, should be a quick read and written specifically for developers).
Check your event viewer for windows installer related messages. Most of the time it will show the componentID that triggers the repair that Phil mentions. Take this GUID and search your installer or use a tool like InstEd! to open the MSI and search for the guid in the components table.
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.
I developed an office add in and a setup application, but after I install it on my computer, and then I uninstall it, it seems everything is OK.
But when I want to reinstall it, I always get nothing. It seems there are some information retained in the registry. Is there any tools can help me to find them out and solve this problem ?
By the way, I used vsto | local to install my office add in.
And I have completed all the added registry in my uninstaller, but seems not work
Rather than programmatically trying to uninstall, do it the old fashioned way. Remove the add-in via office, let it remove the keys and such, and then try again.
I believe an add-in is saved to:
HKEY_CLASSES_ROOT\CLSID{guid}\addin-name\keys
HKEY_CLASSES_ROOT\addinName
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\product\Addins\addinName (all users entry)
HKEY_CURRENT_USER\Software\Microsoft\Office\product\Addins\addinName (current user entry)
and, depending on the system, the Wow6432Node as well under HKLM &/or HKCU
I've found that the click-once cache sometimes hangs on to these old versions and won't let you re-install. You can try a couple of things:
1) run the utility from MS called Mage. You want to run "Mage -cc" which clears the cache.
2) if that doesn't work you can add the environment variable: VSTO_SUPPRESSDISPLAYALERTS and set itto 0. Try the process again. This will give you a more detailed pop-up of information.
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 used windows installer (msi project) and actually I have the msi file after installation it throws a shortcuts to the desktop.
My problem is when i double-click on the shortcut for my application, it displays somthing like the installation then it runs my application. I don't want the installtion windows to appear where my application doesn't need to throw any file or to install something before running all pre-requests are installed through the msi file. I want that when the end-user clicks on the shortcut, it runs the application directly ...
I hope I explained my problem well.
One additional note i'm using VS 2005, C#
What if i want to remove this action where it always happens. everytime i double click on the exe file it appears this window . my application is not so complicated to so.
EDIT: where can i find the log file ?!?
please help.
thnx indavence
One of the "features" of the MSI installation system is that it can automatically repair some things when your application is run.
A good way to see this in action is to have two versions of Microsoft Office installed side-by-side. After running MS Word 2007, an invocation of MS Word 2003 will start with MsiExec popping up to fix a few things before the application starts.
Almost certainly, what you're seeing is this kind of repair - check the log file and find out what is being fixed, then alter your installation project so things aren't broken on first install.
Hope this helps.
That quick installer operations you saw is very often issue. I think it appears only on first run and never again. Never mind. Maybe Windows Installer service makes some registration, etc.
You might want to refer to How Windows Installer Shortcuts Work and Windows Installer Logging
The easiest solution if you really want to avoid this behaviour is to manually add a shortcut rather than having Windows Installer do it for you.
My guess is that you've probably got some HKCU keys in the installer that need to be checked/repaired for the current user. Have you run MSI validation? This can often highlight issues that cause unnecessary repairs.