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.
Related
I'm developing a Visual Studio application with WPF, but right now is the moment where I have to choose my installer.
I need my project to be able to write on the GAC and on registry, but I'm not sure if I should use Visual Studio installer or Wix... I can't find on Google information that says exactly the differences between both of them.
I found that Wix is more complete, but I can't find any article that specifies real differences between one or another...
Can anyone help me to find more specific information or to choose between both of them?
EDIT: Sorry, I specify:
I'm using Visual Studio 2010 professional.
The end product is the same, a windows installer msi.
It's just different how you get there. With the old vdproj there wasn't much other than setting up files to be copied and registry keys as far as I remember. Anything else and you would have to create a custom action in C++ or VBS, not a particularly easy task if you are .net developer.
However with the advent of Wix there are a lot more in-built custom actions which enable you to create a rich installation experience and if you need to create your own custom action you can use .net. Also it is much easier to create a bootstrapper which can install dependencies along with your msi as well as being able to create a front-end in WPF.
As #nvoigt said the old vdproj type is not supported in VS2012 and it also cannot be built by a build server without doing some nasty setup (you have to install VS).
All in all there really should be no question of what to use, Wix is the way forward.
Caveman_Dick wrote:
"Anything else and you would have to create a custom action".
And that in a nutshell is the difference. Visual Studio Deployment Projects heavily abstracts you from the underlying windows installer and seals away a great deal of it's ability. This goes against the very design of Windows Installer which is supposed to be a declarative, transactional programming model.
Take installing a Windows Service as an example? Windows Installer has the ServiceInstall table. VDPROJ fails to expose this so you are off writing brittle custom actions resulting in a less elegant and less robust installer.
WiX on the other hand is a very thin abstraction. It's all about XML XSD elements and attributes that represent the underlying Windows Installer table data. The build process simply transforms the XML to SQL tables. If MSI can do it, WiX can (99%) do it.
VDPROJ was a horrible mistake and Microsoft has finally owned up to it and killed it. Now WiX doesn't have UI designers ( I've written one on CodePlex though) so you might also want to consider InstallShield Limited Edition (FREE).
Using a combination of ISLE and WiX I can get the best of both worlds.
With Setup projects no longer shipped with current versions of Visual Studio, you might want to use Wix. Otherwise, you will have to write it again once you switch to a current version of Visual Studio.
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 was wondering if anyone knows how easy it would be to convert an install project created with the standard visual studio 2010 install project to a WIX project.
This install project has a custom actions dll as well. I read about Heat but I'm not sure what it does.
I'd describe the process more as refactoring then converting. For example, the custom actions you are using very well may not be needed. Often times CA's are used to do things that MSI supports natively such as installing a windows service. (Reinventing the wheel.)
I approach situations like this with:
1) Examine the VDPROJ and custom actions for intent.
2) Possibly use Dark to decompile the MSI to wxs files.
3) Reauthor the WiX as cleanly as possible.
I've done this many times so it's 'easy' for me. If you don't have the underlying Windows Installer experience and/or WiX experience, it'll be far more difficult yet also rewarding in terms of building your skillset.
Using VB6
I want to setup the Project, Last time I used VB 6 Package and Deployment wizard. It asks to modify some system file. I modified my system file, and then it worked. Now again I want to setup my new project, is asking to change the system file.
Once I set up the project, is asking to change the system file and crystal report files (like crystl32.ocx… etc)
Is showing error like, “out of stack space”, “out of system date” etc...
Why is always asking to change?
What is best way to setup a vb project? If there is any software is available for setup a project.
Always am getting a problem for setup a VB 6 project, please Can any one help to solve my problem?
I've been using Advanced Installer (for VB.NET projects, but that doesn't matter), the free version is very capable and easy to use.
But to answer your question, sounds like the package wizard has got itself in a bad state. I'd re-install VB6 in that case.
In my experience the VB6 Package and Deployment wizard is pretty useless. I recommend you look at commercial installation software like InstallShield or Wise.
If you have Visual Studio 2002 or above, you could also try hacking a .NET setup project to install your VB6 components. It is capable of self-registering COM binaries, creating Start menu shortcuts, etc.
Have a look at the answers to these questions
What is the best simple install system [for VB6 programs] on Windows XP and Vista
What is the best choice for building windows installers
Do you have a copy of Visual Studio? You can use that to create installers instead.
You may use some other thirdparty software like installshield to create the setups. As far as I see they are much flexible.
Wise installer is one of other similar products.
Microsoft is now offering a replacement for the Package and Deployment Wizard that may help you out. Visual Studio Installer
I think most people here understand the importance of fully automated builds.
The problem is one of our project is now using an integrated Visual Studio Setup project (vdproj) and has recently been ported to Visual Studio 2008. Unfortunatly, those won't build in MSBuild and calling devenv.exe /build on 2008 just crashes, apparently it does that on all multi core computer (!!!). So now I have the choice to either rollback to .Net 2.0 and 2005 or simply ditch Visual Studio deployement, but first, I'd like a second opinion.
Anyone knows of another automated way to build a .vdproj that will not require us to open the IDE and click on stuff?
WiX was what I had in mind when saying we would ditch vdproj. Do you have any experience with it, good things, caveat?
The low cost solution is to switch to using ClickOnce, which you can automate using MSBuild. But if you still need to create a Windows Installer package, you will need to convert your project to WiX (pretty straight foward) and build that with your solution.
This will get you started:
Automate Releases With MSBuild And Windows Installer XML
I've used WiX a little bit before, and generally I found that it's great once you figure out what to do but there is a steep learning curve. If you spend a solid day going over the WiX tutorial you should be be able to get 80% of your setup working.
WiX Toolset Tutorial
I had the same requirement and ended up using what is suggested in these two links
David Williams Blog
MSDN article
Basically, since Team Build, by itself, will not build the setup projects for you, this approach has you add a new build step after the regular build is complete. This step fires off a second build by launching the devenv.exe. The IDE will build your setup files. The extra build is a bit costly but we only needed it for builds that were going to be pushed out. The Daily build at most would need this customization our CI build does not need to build setup files each time.
After that you execute some Copy commands, once again build steps that show up in your Team System build results, to move the setup files to a network share etc.
It feels a bit like a kluge at first, but it does work, it is also a full-fledged part of the automated build in Team System so it worked for my Continuous Integration goals.