Develop Reference

Merge Multiple (setup) Files into Single Setup

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.

some computers, the "Windows Installer" is retrieved again from the C # program that was loaded when the program was run

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.

Detect All Users .msi

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.

MSI auto-repair issue work around?

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.

Why the shortcut created by my MSI install start the setup process again each time?

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.