Additional Setup in Visual Studio Installer Projects

Short Version: In essence you will need a deployment tool. List view of major deployment tools. Maybe that list view is the easiest overview? (a sense of scope). Much more detail below (and too many links too).


Details: There is some prerequisite functionality available in Microsoft Visual Studio 2017 Installer Projects, but I am unfamiliar with the details. I find this project type inadequate for real deployment work for a lot of reasons (lacking features and some odd implementations). More on this here – a few concrete problems to consider.

Several commercial tools will do this for you with special features to help make it quick(er). I verified that Advanced Installer can do it (and here is a great gateway to all things Advanced Installer. Some free features available). I assume Installshield can do it as well (certainly for other runtimes, didn’t verify this particular one). Generally it will be handled by a setup.exe bootstrapper / chainer embedding all runtimes along with your own MSI file(s).

In other tools, you will have to do it yourself, by figuring out command lines and how to handle error conditions. There are some hints here (not tested by me – a google sweep will give you more): https://www.itninja.com/software/microsoft/access-runtime/2016-1

Get more command line info by going accessruntime_4288-1001_x64_en-us.exe /?:

command lines access 2016

WiX is free and open source – with a relatively hefty learning curve if you don’t know MSI, and contains a bootstrapper feature called “Burn“. Here is the documentation for: How To: Install the .NET Framework Using Burn (first read the “Building Installation Package Bundles” instructions in “Step 1”). A real-world Burn sample. And some sample source markup.

Some developers recommend the dotnetinstaller bootstrapper. Not something I know much about. It is just a bootstrapper. Runs things in sequence for you.

If you are doing in-house or ad-hoc deployment, even a batch file could do the job I suppose, but if you do that for a real product for large-scale and generalized deployment I would be very worried indeed. If there is one thing we hate as deployment specialists, I’d say it is batch files embedded in packages. Batch files (and scripts) are system administrator tools, not general deployment tools.


Some Older Links:

Leave a Comment