I created a MSI installer by using Visual Studio 2008. I have some temp files that need to be deleted after the installation, but the auto-repair feature bothers me. The auto-repair feature will be triggered by clicking the shortcut created by the installer. I am thinking about creating my own shortcut to avoid that auto-repair. I tried this by manually creating a shortcut after the installation. It worked.
Now I am trying to find a way to create a shortcut in a custom action of the installer. My question is is there any possible negative effect to the installer and the installation result?
thanks
Even if you managed to intentionally circumvent Windows Installer, the files will still come back if the user hits the Repair button in Add/Remove programs. Instead you should be looking at ways to make the files temporarily available during the install without actually installing them. Sadly VDPROJ is so limited that it doesn't make this very easy to do.
However, if you want to ignore all that and just hack through the problem, take a look at running post build scripts against your MSI to make the shortcut non-Advertised.
Related
I have a project (Outlook desktop add-in) in the following stack:
C#
Dot net pre-requisite 4.5.2+
When I build the application, I get a setup folder of 3 files/folders:
setup.exe
project-vsto.vsto
Application Files - folder with dll.deploy and manifest files
When I run this exe manually, I can see the installation in my control panel and things work fine.
Now, for mass deployment purposes, I package this folder using advanced installer, through which I create a packaged msi of the project.
On manual installation of this msi, it does 2 things:
"Installs" the packaged project. It can be seen in the control panel. However, this is not the actual thing, more like extraction of files in "C:\program-files..." and we need to run the "setup.exe" here.
Runs the setup.exe, as it is mentioned in the exit dialog at the time of msi creation. This is actual project installation step.
However, when I deploy this through SCCM or GFI (Languard) (which we will be using for mass deployment), second step does not follow. What is the work-around through this?
Is there any thing in advanced installer which I can do to omit step-1? I have read docs etc but could not find other than doing this through custom actions or exit dialog (I've tried both, obvs) which behave in same way as far as my situation is concerned.
Or,
Can I tweak some setting in SCCM or GFI (maybe add custom action there, or some installation switch, or some other setting?!!) which can help me achieve my purpose.
Any leads which can help my cause will be greatly appreciated. Thanks in advance.
Most likely you didn't use the built-in support Advanced Installer has for Office addins.
Here it is a video tutorial about how to create a setup package for an Office Addin with Advanced Installer:
Package Office addin with Advanced Installer
Try to follow these steps and check the outcome.
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 have an application that was created using Visual Studio which contains an installation project. When I run the MSI that is built, 3 Windows Services are created. Everything installs fine, the services are there and I can start them, when I choose the option to install for "Just Me".
When I choose the option to install for "Everyone", all users on this machine, the services are still installed fine and I can start them while I am logged in as the same user who installed them BUT when I log in as a different user and try starting the application using a shortcut, the installer starts up and tries to uninstall the services. Weird thing is that it only uninstalls 2 of the 3 services.
Again, if I install using "Just Me" I am having no issues at all, it seems to be linked to the "Everyone" option. I am not sure how to even begin looking into this as I am new to setup projects (this project was created by someone else) so any help would be great.
I'm thinking in one of the installation folders a file must be missing for the second user and that is why the installation folder opens up again?
Thanks for any help.
SOLUTION:
The issue was with the DISABLEADVTSHORTCUTS property of the MSI because the shortcut that was installed for everyone was an Advertised Shortcut as far as I understand. There are a few ways to get around this using a post build event or using ORCA...we ended up using ORCA and adding the DISABLEADVTSHORTCUTS = 1 property to the MSI.
Solution and better explanation:
https://jcrawfor74.wordpress.com/2011/08/17/setup-app-config-during-msi-install-msi-re-installing/
https://support.microsoft.com/en-us/kb/255905
Try to find the called schema.msi under
C:\Program Files (x86)\Microsoft Visual Studio
This prototype is used in the consecutive generation of your deployment msi file. Then, you can use orca to add DISABLEADVTSHORTCUTS=1 to the Property table. So, from then on, all of your msi files will create the standard shortcut.
I created my MSI installer for our C# application via VS 2008. I installed it. It created a shortcut for me on the desktop. I clicked that shortcut, the setup process running again and at the end our application was launched. It was not like this yesterday before I added some custom action to create database. I didn't recreate the shortcut in the installer. why it is like this?
Open the MSI manually using Orca. Add the following record to the Property table (Property, Value) without the quotes:
Property = 'DISABLEADVTSHORTCUTS'
Value = '1'
This can also be scripted and run as part of a post build event.
MSI comes with an auto-repair feature that checks whether all components installed by MSI are still present when you launch your application using the shortcut.
In your case, probably one (or more) components have been removed so the installer is launched again to repair your installation.
To prevent auto-repair from running either
Make sure no file, registry setting or other installed component is removed
or
Don't set the key path for those components. That will prevent MSI from checking those specific components
From your other questions it seems that your MSI has been created by a Visual Studio Setup and Deployment Project. Unfortunately, there is no option to modify the key path from within Visual Studio. You have the following options:
Modify the MSI manually using Orca (This is not a good option because it is a manual step)
Write a script e.g. using VBScript to patch the MSI file
Move to a more advanced install system which gives you more control such as WiX or NSIS
Is the shortcut pointing to your application or your setup? If it's pointed to your setup and you change it to your application, does the problem go away?
Sounds like the system thinks the installation has been corrupted and is automatically attempting a repair,.Anything in the event logs (look for source of MsiInstaller in the Application Event log).
Have you been building multiple copies?
This happens when the application deletes a file that was deployed during the installation. The Auto-Repair is activated and hence you get the installation screen.
Had the same problem. In my case it turned out the issue was 'Manufacturer' and 'ProductName' fields inside Deoplyment Project properties. It needs to be the same as the folder structure your shortcut is pointing to, otherwise you'll end up with the 'The resource 'C:\Program Files (x86)[Manufacturer][ProductName]\' does not exist' error inside Event Viewer.
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.