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.

How to create an executable to update a DLL in an installed application

I am looking at making an application more modular and accessing dlls so that I can change them if the client was wanting different functionality.
I know how to create the dlls and reference them, but I am trying to find a way to create an executable that will install a different version of a dll into the required application folder. I want to avoid having to put the new dlls into the original project and build a new install file and I want to keep things simple for the end user.
Currently I am using visual studio 2010

You could create MSI files for each of your dlls and use the standard installer process to update the dll. It is also possible to write an exe that downloads and extracts which will have an arbitrary amount of logic (licensing, download location now and then...).
A combnation of both might seem an interesting thing. A bootstrapper downloading msi files and silently installing them. You could have advanced features in the installer while having the freedom to decide what and when to install on your own.
Technical aspects popping into my mind: files in use may not be changed and if you change the interface theunchanges main program won't be able to use the new library.
It seems you're searching for a plugin architechtecture, you might want to look at MEF or Unity to perform the compositiom, but that is more a side comment.

There are few SO thread available on this great website. You should explorer them and try the best way to implement whatever situation you have..
Check these reference links:
from: Creating a patch to upgrade .NET application
If you already use a a VS Setup Project you can deploy the new version
of this project and it will upgrade existing installations. Have a
look at the setup and upgrade ids. The stop and start of the service
can be done by custom actions that can be defined in the project and
will be executed i.e. when your setup is committed or rollbacked etc.
Patch development in DotNet
How to make Patch-able/Update-able application?
create patch file using .net windows application
Note: Ref this For clickonce how to build a patch for existing installer

how to use VS Setup and Deployment project and build an .msi file to install the program?

i wanna deploy a C# Windows Application project using Setup and deployment project technique
but i don know what should i use
after i open File > New > Project > Setup and deployment > ....
then what ,, what should i do next

In the past I've used the Visual Studio Setup Project or Innosetup for my programs. I prefer to build .msi's over exe's so Visual Studio Setup Project has been my goto for a while now. It is however, very lacking in capabilities. The interface is not intuitive either in my opinion. Every time I build an installer there is a lot of trial and error install/uninstall to get it right. Other's have pointed out WIX and I've looked into it. It appears to be very flexible and since it is open source, we should be able to count on it for the long term.
Here is a recent article about WIX. What I found interesting is the article claims (see link in article) that Visual Studio Setup Project is being End Of Life'd in VS 2010 + NEXT_VERSION. This is a little disconcerting to me. Since I don't want to begin to rely on the new Install Shield "Lite" in VS, I'm going to put effort into learning WIX. I hope it'll pay off in more flexible builds for my applications as well.
All that said, when creating a VS Setup project, I usually use the wizard to put in the initial plumbing. You'll point it at the files you want in the .msi. Typically for me this means the "outputs" of one or more programs in my solution. Any managed assemblies referenced in the programs will automatically get picked up as dependencies and included. Unfortunately unmanaged assemblies don't and I usually have to add them manually using the "File System Editor" mode in the Setup Project UI. Adding shortcuts is a little hokey as well. You right click under the start menu and desktop section of the "File System Editor" mode and select create shortcut. This is all by memory so hopefully I'm getting this right. You will certainly have to test your installer multiple times before you get it just how you want. I like to test under a VM as well.
Finally, the VS Setup project produces a setup.exe and .msi file. Setup.exe is used for detecting and installing dependencies (such as .Net) before unpacking the actual DLL.

When u do this File > New > Project > Setup and deployment >
then right click Application folder> Add > File...and add your app's .exe file and also you can add shortcuts of your app in desktop and program's menu

I would recommend you to go for some tool for creating msi.
I am using WIX

What you need depends on... what you need.
For a large percentage of applications, all you need the installer to do is let the user choose an install location, copy files to a directory structure at that location, and create a few shortcuts. For that, a Visual Studio Installer -> Setup Project is fine. It can handle this basic functionality, as well as installing prerequisites like the .Net Framework redistributables, providing custom install options, and/or writing simple registry keys. The Setup Wizard creates a Setup Project as well, but runs you through a wizard to set up the basics. This is a good option if you've never created an installer before.
If you want this application to be controlled by a larger, more custom install, choose the CAB Project; it will simply pack the necessary files into an archive that is easily accessible from another setup project.
If you are publishing a class library, use a Merge Module. Merge Modules work within install programs themselves, providing files needed for the main application to work.
If you need serious customization, or you want to interface with existing InstallShield logic, I'd get a third-party installer. I've worked with InstallShield before, and it's pretty full-featured, but by the same token, the installers it creates are applications in their own right and can take days or weeks of logic programming to "tweak" to your satisfaction.

Configuration file 'C:\my\App.Config' is being used to configure all executables

I have a Visual Studio setup project that installs an application into the task scheduler and also installs a GUI application to manage some configuration parameters in the registry. This being the case, the setup project installs two different primary outputs (.exe's) as part of the process.
I am getting the following warning when I rebuild the setup project:
Configuration file 'C:\my\App.Config'
is being used to configure all
executables
Is there any way to remove this warning? The suggested MSFT solution apears to be to use a different setup project for each .exe, but I only want the users to have to run one installer. Any suggestions?

There was a <runtime> section in my App.Config file and once I removed this portion of the config file the issue went away.

Maybe you could create an installer that launches all the other installers.
This isn't a particularly helpful on microsofts part is it?
Another idea might be to take their advice and use either no config file or a custom file format so that you avoid this error.

From Choosing a Windows Installer Deployment Tool, it looks like the built-in windows installer maker is essentially deprecated ("Future versions of Visual Studio will not include the Visual Studio Installer project templates.")
This page also recommends InstallShieldLE and Windows Installer XML Toolset. I've just used InstallShieldLE to create an install that includes multiple executables and it appears to have worked (I'll edit this if it turns out it didn't work).
For very complicated installs, I've used NSIS in the past with great success - I'm not sure how much extra effort NSIS requires over InstallShieldLE for simple installs.

Visual Studio 2008 - Issues with publishing C# Console Application

I have a C# console application written in Visual Studio 2008.
Usually I just build the application and then copy the files from the 'Release' folder but this time trying to do it 'properly' by publishing the application.
I went through the 'Publish Wizard' and end up with a 'Setup.exe' file in the specified folder. When running this setup file on another computer the install fails and indicates via a error message that:
Cannot download the application. The Application is missing required files...
When I select the 'details' button the error log shows that the program was trying to download files from the last version directory (ie 1_0_0_4).
What am I doing wrong? (aside from being tired...)
Show I de-activate the version auto-incrementing?

Unless you have a valid reason to do so, I would abandon the publishing and just go back to the XCopy installation. (And by Valid, I mean something other than someone told you that it's the "proper" way to do it.) I base this advice on the following arguments:
We used ClickOnce for all our WinForms apps for a while, but eventually it got to be more trouble than it was worth. For one thing, you need to deal with the security certificates. We had issues when we replaced a server with a new one with a different name, then we had issues when we replaced our development machines, etc.
You said this is a console application. ClickOnce publication seems to be overkill for a simple console application unless there are third party dependencies that you need to include in your install.
Don't get me wrong, I liked using ClickOnce for the ease of putting updates out there, and we use it still when it's the best option. However, in your situation, it looks to me like XCopy deployment should be sufficient for a simple console application.

Not knowing what you choose in the wizard, web or CD, the setup.exe file needs to be able to reference it's installation files. If using the CD method, you will notice in the output directory you revision directories, e.g. 1_0_0_4, where each revision of your app is kept. I agree with #David_Stratton, and unless you really need to use one-click publishing, don't. Just use xcopy (robocopy), zipfiles, etc. It will greatly reduce your stress levels down the road.

Everything David Stratton has stated is correct. ClickOnce is overkill for what you're trying to do, and publishing through Visual Studio has always given me headaches.
I might recommend taking a look at NSIS if you're looking for generating an installer for others. It's relatively simple to generate full installers that merely grab files from your /Release/ directory, with plenty of sample code for getting an installer working quickly. Once you have your working script, making your installers are as simple as a right-click and clicking compile.