I've got a question about installers.
At my workplace we have a development environment which envelops quite a lot of IDE's and plugins for those IDE's.
I've just started working there and I have yet to set up my development environment. However keeping in mind that they will hire new Juniors within the next couple of months I thought it might be a good idea to create an installer that calls all other installers, essentially making an installation bundle of IDE's.
Now here's the catch. I know it should be possible with visual studio but I can only get my hands on the Express edition, and I doubt they will get a professional edition just for me.
So my question is, how do I create such a bundle installation? I can work in virtually any environment but at work we have Eclipse and at home I've got VS Professional (but no access to the files I need).
Any help is welcome, Rope.
Since you are interest in a free powerful tool the only one I can recommend is Wix, and its new feature called Burn, used to handled installation package bundles. There are payed tools that can help you get this done much faster, but you'll need a little budget for that.
Related
I've been tasked to create an installer that will handle and install multiple .msi files. I nearly went down the InstallShield route, but you need to Premier edition to create Suite installations, and to say you're paying almost £3000 doesn't even let you fully customise the UI.
For our last release I wrote a custom Setup.exe file which looks in the same folder that it is stored, for the msi files we wish to install, and then silently installs each one. It's pretty basic though, and we now need something more professional.
At the moment I've got 2 main options:
Use WiX - This is free and seems to offer a lot of customisability. I'm not too sure yet what exactly it can do, and it will take a bit of time to learn.
I can expand upon what I already have and build my own installer that allows the user to pick which features/components they want to install and which they don't. I would prefer this if I could get the installer to download the required msi files from a server, install them, then delete them. I just don't want to have to include a separate folder full of msi files with the main setup download. Would this be possible without TOO much effort? Also, using this would I be able to add a single program to the Add/Remove Programs menu?
Any ideas welcome :)
I would recommend checking out the features of Burn in WiX 3.6. You can create a bootstrapper and it has the capability to download your installation packages from a server. You can fully customize it or use the standard bootstrapper application. You can use your current .msis as well. You don't have to convert all of your .msis to WiX to use the bootstrapper functionality.
I'd recommend reading this blog post by Rob Mensching.
How effort free it is depends on how complex your set ups are, the interdependencies and their pre-requisites.
For instance you want to install product X, but it needs a database server installed, which need a .net framework upgrade, which need reboots..
Wix is for creating msi's so it would only be a help if you wanted to create an msi could manage the install of several apps.
WiX 3.6 is still a beta project and Burn is still a work in progress. Truthfully InstallShield Suite installers are pretty new and still a work in progress as well.
Before you get all freaked out over the cost of InstallShield, you need to decide exactly what your setup.exe needs to be able to do. Then you need to do a feature gap analysis between InstallShield and WiX and come up with labor estimates for rolling your own, doing it in WiX and doing it in InstallShield.
It certain situations the off the shelf tools aren't mature enough and it makes sense to roll your own. ( Think MS SQL Server, Office, Visual Studio ) but for most line of business applications you probably just need to pick the tool that gets you closest to where you need to be.
For something that needs to be a little bit more professional than your own custom setup.exe, with less of a learning curve than WiX and Burn, and less of a pain on your wallet than InstallShield - I would suggest MSI Factory, not for MSI Factory (it would speed up your WiX learning though) but for the bootstrapper thats included.
The learning curve is less than Burn, and there's a 90 day trial so you can see if its good enough for you.
InstallShield will let you customise the installation interface, and for that hefty price tag you get support and maintenance (very useful when you're ramping up from scratch).
What you save on up front cost with InstallShield, you'll invest in terms of time with WiX - so you really need to do a cost/benefit analysis and figure out how much your time is worth. InstallShield is just as powerful as WiX when you really start to understand Windows Installer and what's under the hood. Many commercial developers will use elements from both depending on individual project requirements.
I've not messed with installing software probably since early 2000s but I was wondering what the ideal way was now. I used to use InstallShield but I sorta remember VS.NET having their own install service that could be used?
What I need to be able to do is copy/create files and insert paths/values into config files based on where the install installs the files. Can this be done with VS.NET or do I need a 3rd party tool?
Using Visual Studio 2010 has setup projects, but they are going away in VS 11 (http://blogs.msdn.com/b/buckh/archive/2011/03/17/visual-studio-setup-projects-vdproj-will-not-ship-with-future-versions-of-vs.aspx).
Wix is an option, but the learning curve is rather steep.
InstallShield is also still an option.
I recommend innosetup
http://www.jrsoftware.org/isinfo.php
It uses a reasonably easy to learn proprietary script and for me works every time
I've no idea if MS have their own means in VS.NET
Why should one go for Windows Installer XML (WiX) when we have in built .net MSI installer?
It would take me hours to rant about everything I hate about VDPROJ. I won't because in my (expert) opinion it's already settled law that VDPROJ sucks. If your install is so simple that you haven't noticed any problems, then be my guess and stick with it. But if you already find yourself fighting the tool trying to get it to do things it doesn't do, then take my advice and dump it fast for WiX.
10 things I hate about VDPROJ
No MSBuild Support. Sure, you can call devenv from the command
line but it's not as good.
No exposing of the critical concept of
a component. Every file/reg key is a keyfile of it's own component.
No effective way to fully exclude automatic dependency scanning.
Shortcuts are always Advertised
No way to describe a service.
No way to describe many things which leads to overuse of custom
actions.
No way to fine control the scheduling / execution of
custom actions. Too abstracted.
Abstraction is wrong. Deferred
CA's are scheduled with Impersonation which breaks on Vista.
Various limitations lead you down a path of massaging the built MSI
during postbuild to get around all the limiations. Results in a
very poor build automation hacks.
Merge Module directory tables
are authored incorrectly.
100 other things suck that I'm not
remembering right now.
The introduction of WiX tutorial gives the basic idea about WiX advantages comparing to other setup development tools (including VS setup projects):
declarative approach
unrestricted access to Windows
Installer functionality
source code instead of GUI-based
assembly of information
complete integration into application
build processes
possible integration with application
development
support for team development, both
in-house and third-party
free, open source
Hope this helps.
Visual Studio deployment packages can only be built by visual studio. They cannot be built using plain MSBuild command lines, which makes them less than ideal for e.g. build servers.
All the above answers have included most of the annoying features of Visual studio setup projects (.VDPROJ), one thing that most people have missed.
.VDPROJ file format is such that, and if we make a small
change to one single entry it completely rewrites all the entries
within which makes it impossible to merge changes from 2 different
branches.
Some of us don't want to use / can't use the .NET installer.
Some of us don't want to have to install Visual Studio to distribute a program, written in, say, Borland Delphi. WiX and .NET have nothing to do with one another.
WiX provdes a much more complete feature set than the .NET installer.
Taking into account that some Windows Installer products from independent vendors (for example IstallShield) are rather expensive we can say that using a setup project in Visual Studio for building Installation packages has some drawbacks. Otherwise why developers should buy something else.
For what reasons developers could use something else (not Visual Studio) for building their setup packages?
Generally speaking the third party installers let you perform very complex setup actions relatively easily. Not to say that most things cannot be done with VS, but there can be quite a bit of hand coding for custom install actions. The third party tools hide a lot of this manual work.
Last year I heard that Installer Projects were going away and we should be switching to Windows Installer XML. Whatever happened with that?
So you know where I'm coming from, support for TFS-based buil machines is very important to me. I know Installer Projects kinda-sorta work with TFS, but they have issues.
IronRuby uses Wix, but that requires upkeep and scripts. I haven't looked into parrafin or anything like that yet, but the mix of a Parrafin (like) script and WIX would probably work well.