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.
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 need remove add-in Outlook programmatically.I remove the corresponding entry from the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins and HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins.Than Add-in dissappear from Outlook
but in directory "C:\Users{username}\AppData\Local\Apps\2.0\" remain dlls add-in and in windows menu "Remove and Update" so remain. Can I fully remove add-in?
Normally you remove programs by simply running their uninstallers (add-remove programs panel does exactly that). You can find uninstaller command lines to run in the registry key Software\Microsoft\Windows\CurrentVersion\Uninstall
For programs installed via windows intaller (MSI) you can (actually, should) use Windows API to uninstall them, provided that you know what to uninstall. See here
If the add-in you are trying to uninstall was deployed via Click Once (looks like that), you can still use uninstall command line, but AFAIK there is no straight way to do that silently. See here.
I'm trying to deploy Outlook add-in with ClickOnce.
While setting the update options I noticed that there are fewer options available for Outlook add in project than there are for Win Forms project. For example I cannot specify minimum required version. Why is that? Also, I would like:
to enable manual update
to ask user if he even wants an update (if it is not required).
1) I tried using System.Deployment.Application and CheckForDetailedUpdate() function but even though update succeeds there are problems installing it: If i restart my plugin it disappears from Outlook, if I don't the old version gets stuck in Outlook (and behaves oddly) although further updates via UNC path suggest that update has been successfully done.
2) Regular publish with no special options added with Mage or MageUI works in itself, but add-in seems to update without asking a user. Googling a bit reveils that people are trying to do the opposite, so I'm kind of puzzled as to why doesn't it prompt for update by default.
I tried editing manifests generated from Visual Studio with MageUI but it generates invalid XML for application manifest (?! - it misses "assemblyIdentity" node in "dependentAssembly" node), and when i add missing nodes from original manifest generated by VS (and update and sign it afterwards), installation complains about assembly hashes being invalid.
How can I deploy Outlook add-in with said requirements?
VSTO applications (Office Add-Ins) only support certain bits of ClickOnce. You can try adding code and doing programmatic updates, but the ClickOnce lead at Microsoft said it is not really intended to be used, and parts of it might not work. (No, no details on exactly which parts -- you have to do a bit of trial & error).
Also note that the way a vsto deployment works and runs is this: Outlook checks out the vsto app, and copies the dll(s) to a shadow location and loads that with Outlook. When you update the vsto app, it updates it in the click once cache, but not in outlook. When you close outlook and re-open it, it finds the new version, copies it out to the shadow location, and loads it. You can't restart the vsto bit itself and have it do anything. The user must restart Outlook.
This is one of the reasons that updates are performed when starting up the Office application. It looks for the new version, updates if necessary, and then loads it into Outlook and uses it.
Having said that, another way to accomplish what you want is to write a windows forms app that will update your add-in. Basically deploy a winforms app that just shows nothing the first time except invoke the vsto application via clickonce (process.start is your friend). Then you could have the outlook add-in invoke the winforms app the see if there's an update, and if there is, it could prompt for an update of the win forms app, and then uninstall and reinstall the office add-in or update it.
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.
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.