3

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

follmer
  • 997
  • 3
  • 12
  • 28

1 Answers1

4

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


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:

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).

Alternatives:

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).

Stein Åsmul
  • 34,628
  • 23
  • 78
  • 140
  • It is true that when starting to work with `Visual Studio Installer Project Extension`, you are seeding a plethora of root causes for later self-evolving problems. The most prominent effect is that your setup almost always stops working over time and you need various workarounds to get it to work again. This applies to complex projects/solutions. IMHO this tool can be used to get a quick setup for simple projects though. Cause it is set up quite fast. But this is its only advantage I can see! ;-) – Nicolas Aug 23 '19 at 12:14
  • Yes, it should be easier to make a quick setup. `Dark.exe` from the WiX toolkit can decompile an existing MSI file to WiX markup. Needs some cleanup but works well to convert. Advanced Installer - and I think Installshield as well - can import VS Installer Projects as well. Some paths to help yourself when stuck. – Stein Åsmul Aug 23 '19 at 12:19