Asked  7 Months ago    Answers:  5   Viewed   34 times

I've got a sizable project, with multiple classes, 500+ images, and 20+ text files associated with said project.

I've been publishing my project via right clicking on the project->properties, and clicking on the publish tab. I've included the text files and images as resources already.

The issue is that whenever I install an application, usually it's a simple installer, i.e. you download an installer (one file such as installer.exe), run this file which then takes you through the setup, such as where to install it to, etc. Then the application is installed and that's it.

Well, when publishing my application, I specify an output directory, and I'm left with these files:

  • Application files
  • MyProjectName.application (the manifest?)
  • setup.exe

If I run setup.exe, I'm able to install the application and run it with no issues. However, not only does it not let me choose where to install it, but I would have to send all 3 of these files to the user. I tried to send just the setup.exe to a friend and it said they were missing the files required (which I'm assuming is what the application files and .application were for).

How would I go about bunching these all into one installer, one that more closely matches how you would install an enterprise application (think of installing chrome, eclipse, photoshop, etc)?

I've love to be able to have one file which is the installer and be able to have users download that.

Thank you



The Ancients: If the below is TL;DR (too long, didn't read), please skim these two links:

  • Troubleshooting Setup and Deployment Projects
  • Why use Windows Installer XML (WiX) over VDPROJ?

UPDATE: September 2018 - Since this "answer" was recently downvoted, let me try to add some more links to see if the intent of the answer can be made more clear. Not to be overly dramatic, but:

As deployment specialists we have to warn people when they commit to using a tool that is bound to fall apart for them down the line when more advanced deployment requirements invariably surface.

The installer projects have several times been pulled back and then re-introduced in Visual Studio. Always based on the problems seen with these project types (just the bigger ones):

1) No MSBuild support (not tested extensively by me, but by others), 2) only deferred mode custom actions running in system context (not insertable in GUI), 3) highly limited control overall (always advertised shortcuts, no ability to configure certain things, etc...), 4) no support for proper service installation - requires custom actions instead, 5) very few available prerequisites to bundle, 6) rudimentary GUI with little flexibility, 7) appears to not be possible to define MSI features (as in features and components), 8) problems with 32 / 64 bitness issues for custom actions, etc...

An old MSDN page on this project types and its problems: Troubleshooting Setup and Deployment Projects.

MSI Expert Chris Painter and others:

  • Are Visual Studio Setup projects suitable for complex setups?
  • Why use Windows Installer XML (WiX) over VDPROJ? (recommended)

In my opinion the project type can only work for simple.NET applications. Any complexity of caliber and you are in trouble. SQL Scripts, IIS, proper COM / COM+, Users & Groups, Shares, Firewall Rules, Custom GUI, etc... Commercial tools and WiX have advanced support for these things. The internals of the compiled MSI files are also sub-standard (use of self-registration, custom actions for services, etc...). I often experience that the tool stops working for "some unknown reason" as well. Suddenly it won't compile. Concrete Example (with fix).


  • Simple List View of Deployment Tools
  • WiX Quick-Start Hints (if the tool needs to be free)

  • How to create windows installer (links to all kinds of deployment tools, summary of MSI advantages and some brief descriptions of trending deployment technologies)

The open source WiX toolkit features a component called Burn to create such setup.exe launchers / downloaders / bootstrappers - used to run several installations in sequence and / or install prerequisites (a very common task - Visual Studio projects only support a few prerequisites).

Writing WiX XML markup code is necessary to use this Burn feature. Commercial tools Installshield and Advanced Installer provide GUI-features to build such setup.exe files.

The Visual Studio installer is very limited, I never use it. WiX (link to an answer trying to provide some links for a WiX crash course) is a full blown, open source deployment solution. It will take you a while to master, but it is very good and flexible. A commercial solution such as Installshield or Advanced Installer will allow you to deliver a setup faster and easier, but they can be very pricey.

Given the limitations of Visual Studio Installer projects (and bugs), I do believe the right solution is to use a different tool: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc. If you need anything advanced at all, you will struggle otherwise. With a more advanced tool it is at least possible to do what you need, even if it might be more involved at times.

Let me know what you want to know about such a process, and I will try to help. I am not sure what software you are delivering, what the target user group is, what budget you have, etc... Windows Installer is highly desirable for a number of corporate benefits, but other deployment technologies exist (see the description above of various tools to use).

Tuesday, June 1, 2021
answered 7 Months ago

Almost all C or C++ programs built with Visual Studio 2015 or later will only run (properly) on PCs that have the relevant VC Redistributable installed.

You say you don't want folks to have to install something else - but, one way or another, they will have to. However, as you are building an install package, you can probably set the relevant redistributable as a "prerequisite" in that installer.

This will mean creating a "Setup.exe" file to run the .msi package, though. To use this method, right click on your ".vdproj" project in the "Solution Explorer" and click the "Prerequisites" button. (If this button is not enabled, then be sure to select one of your "Release" configurations in the top-left of the property page.)

When you click this, make sure you check the "Create setup program to …" check-box at the top of the "Prerequisites" dialog, then scroll down and select the relevant "Visual C++ '14' Runtime Libraries" option (one for each supported platform). [Note, although they're called VC '14', they will each work for any VC version from 14 upwards!]

You will then have to distribute both the "Setup.exe" program and your .msi package. When they double-click "Setup.exe," that will check for and, if necessary, download and install the redistributable.

There is another way to do it, by including the relevant, platform-specific redistributable in your install package, then running that as a "Custom Action" from the installer. But this isn't trivial! I can post some sample code for doing this, if you elect to go down this road.

Thursday, August 5, 2021
answered 4 Months ago

What works best is to add following target to the project file:

<Target Name="AfterBuild">
   <Message Text="Copying to Deployment Dir:" />
   <Copy SourceFiles="@(Content)" DestinationFolder="..XXX%(Content.RelativeDir)" />
      <CreateItem Include="$(OutputPath)*">
        <Output TaskParameter="Include" ItemName="Binaries"/>
   <Copy SourceFiles="@(Binaries)" DestinationFolder="..XXXbin" />

This way, whenever project got build (from command line or from IDE) it automatically get deployed to specified folder. Thank you everybody for pointing me to right direction.

Sunday, August 8, 2021
answered 4 Months ago

I've always found the custom dialogs in visual studio setup projects to be woefully limited and barely functional.

By contrast, I normally create custom actions that display winforms gui's for any remotely difficult tasks during setup. Works really well and you can do just about anything you want by creating a custom action and passing a few parameters across.

In the dayjob we built a collection of common custom actions for tasks like application config and database creation / script execution to get around custom dialog limitations.

Tuesday, August 10, 2021
answered 4 Months ago

The answer to your question is also in the blog that you linked to, but it's mentined in a kind of round about way:

If you open up the Property Manager view to see the property sheets associated with your project, you’ll see that one of the property sheets is named Microsoft.Cpp.Win32.User. This property sheet is actually stored in LocalAppData, just as VCComponents.dat file was, in the directory %LocalAppData%MicrosoftVisualStudio10.0. Using the property editor on the property sheet (just right-click on this property sheet node and select Properties…), you can see that you are able to make edits directly to this file. Since all projects, by default, import this property sheet, you are effectively editing the VC++ directories in the same way you were able to do before.

The key is that you get to the VC++ Directories property through the "Property Manager" windows (open it via the View/"Property Manager" menu selection). The VC++ Directories setting is in the "Microsoft.Cpp.Win32.user" property sheet - that edits the global setting, so you should only have to do it once.

There seem to be quite a few people who dislike this change; I think that's because it's less discoverable and obvious than how the setting was managed before. The trade-off is that it's more flexible and integrates into the MSBuild architecture better, and once you do know about it it's just as easy to change as before (it's just harder to find, particularly if you're used to the old place).

Thursday, October 14, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :