Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have a pretty huge web application developed using asp.net 3.5 and I need to prepare an installer package which will be using to deploy the application on IIS 6 and 7. I have done a lot of research on Wix and Installsheild 2010 (pro) and need some advice before making decision. I notice that the installsheild is quite expense in terms of license but for me, I have enough budget so that won't be an issue. the installer should be able to perform the following processes.
Deploy the published web resource
(aspx etc).
Create Virtual
Directory.
Create Database on sql
server and run some initializing
scripts.
Modify XML files and
web.config files.
Set the
permission to allow writing to the
files in the virtual dir.
I found that both technologies are capable of doing the above scenarios but I would like to get personal experience and advices.
Having created a Wix installer to do exactly what you're looking to do, I'd happily recommend it.
The benefits of Wix over InstallShield as I see it:
Since Wix is free, everyone on your team can install it, and thus everyone can contribute to the installer. If one dev adds a library to the project, they can update the installer as appropriate, without waiting for the "Setup guy" to do his bit.
There are no issues with installing Wix on a Build Server, making it a nice fit for an environment where you use Continuous Integration. It integrates nicely with MSBuild (see the Votive project).
Wix installers are built from text files, making them very easy to version control.
Wix includes Deployment Tools Foundation (DTF) which makes it very easy to create custom actions using .Net code.
Wix is close to the metal: you can usually apply your knowledge of Windows Installer quite directly to Wix. Conversly, learning Wix teaches you a lot about Windows Installer which is always good when it comes to providing support for deployments.
To balance this, there are a few things to be aware of:
Wix does have a steep learning curve. If you haven't already, check out the WiX tutorial.
WiX isn't a "visual" environment like InstallShield - it's usually text and xml all the way. Having said this, there are editors, free and commercial.
Specifically relating to IIS setups: Wix 3.0 only works against the IIS 6 metabase APIs. To install on IIS 7, you'll have to enable the Metabase Compatibility feature on the target server. Full support for IIS 7 is coming in Wix 3.5 - I've tried the beta of this, and it seems to work fine so far.
Based on my experience with Wix and InstallShield, I would recommend using InstallShield unless you need a fairly basic and straightforward installer. I say this because the huge Wix learning curve is made even more difficult by the lack of information available
There are no books on Wix, so your resources are limited to the Wix tutorial, which is detailed and lengthy but still doesn't cover much beyond basics, and blog posts you find via Google. Granted, there are many good blog posts which detail how to accomplish specific things, but unless you don't have deadlines to meet, you probably can't afford to sit and research how to do specific things in Wix for days at a time. Personally, I found myself doing this way too much for Wix to be a feasible solution (again, unless you only need a simple installer)
Ultimately, in my case, we had existing installers which were developed with InstallShield and we are simply able to be productive quicker with it. InstallShield also has its own scripting language which has pretty good documentation too.
Another big plus for me was that InstallShield eases the pain of multiple instances (try searching for how to do this with Wix and you'll get an idea of what I'm saying) and upgrading/patching. I was able to accomplish both of these (especially multiple instances) in a fraction of the time with InstallShield than what it took to accomplish in Wix.
My advice would be to choose based upon your time constraints/deadlines/commitments, complexity of your installer, and maturity of your product. Wix requires LOTS of research for things InstallShield provides a fairly quick way of doing. This can be even more painful if you have a mature product versus a fairly young product.
Hope this helps.
To address Samuel's points above....
I've created a project on CodePlex that is called IsWiX that addresses the democratization issue. You use it with WiX to create Merge Modules and then consume the Merge Modules with InstallShield to get the best of both worlds. This allows a setup guy to use InstallShield and dozens of my developers to use IsWiX/WiX. The XML can still be marked up with additional metadata so we aren't restricted in what the modules can describe.
InstallShield has a stand alone build engine that integrates with MSBuild/TFS and provides an automation interface. There is no advantage for WiX here.
InstallShield is a text file also. It's an uglier DTD format but IsWiX solves that problem by abstracting the frequently changing portions from the rarely changing portion of the installer.
I highly encourage the use of DTF with InstallShield. After all a Type 1 Exported Function is the same to any MSI based tool.
InstallShield has a direct editor which shows you the underlying tables. This is actually closer to the metal then WiX which uses an XSD based DSL to output the metal.
All in all, there are really good things about WiX AND InstallShield and I use them together to create extremely complex installers.
PS- IsWiX put a lot of thought into hashing and sorting to solve branch merge problems. ( We use Base Clearcase on dozens of branches so this was very important to us. )
+1 to Samuel's answer. As for the steep learning curve... if you don't understand the way the underlying technology (Windows Installer) works, you'll have problems with the support of your installation, either InstallShield or WiX you choose. But WiX encourages you to learn Windows Installer to use WiX abstractions correctly.
I personally started my setup project (a huge web application) with InstallShield, but I recently moved to WiX and I'm happy about it. The key points of my choice:
it is free
it is XML (no more pain diffing and merging)
it is friendly to NAnt
it does exactly what you instruct it to do (no more and no less)
Hope you find this information useful.
Related
Is there a complete WiX 3.6 multiinstance installer somewhere?
I just do not understand WiX 3.6, I guess. I have been reading for three days to try and construct a working example of a WiX 3.6 that will allow to install multiple instances of an application on the single machine.
Is there a functional example of how to do this with WiX 3.6?
Here's some info I wrote a few years ago... since then, WiX: A Developers Guide to Windows Installer XML has been released and is also a good resource for beginners. I didn't find it that great myself though. I still suggest reading The Definitive Guide to Windows Installer as a starting point. Windows Installer and WiX isn't something you just pick up in a few days, it'll take a few months.
Go pick up a copy of The Definitive Guide to Windows Installer. I've lost count of how many times I've recommended it to people who are getting stuck on the concepts and are struggling to understand how Windows Installer works. Make sure you grab the Windows Installer SDK as well.
Getting to grasp with Windows Installer is the first stage of your learning, once that's sunk in you'll understand how InstallShield works (or doesn't work as the case may be..). Wise, InstallShield, etc try to shield you from the underlying concepts and have their own trickery/hacks to get around the limitations of Windows Installer.
Stage two (if you're serious about understanding Windows Installer) is learning WiX (The WiX Tutorial isn't too bad, although it's a bit out of date and targeted at WiX 2.0 rather than 3.x) and joining the wix-users mailing list. Don't join the users list until you've finished the book mentioned above, you'll be well in over your head. Questions from those who don't understand the Windows Installer concepts largely go ignored, however questions from people who have done their homework will find it a great resource.
What's not covered in the book is Vista, Robert Flamings blog entries on Understanding UAC and Vista (written when Vista was in it's beta stage) are the best information you'll find on the topic.
One thing that both the Windows Installer and WiX teams is really good at is keeping the documentation (Help files) up to date. Whenever I'm working on setups I'll generally have Wix.chm and Msi45.chm open on one monitor ;)
Along with the documentation, blogs from people on the WiX and Windows Installer teams are great for learning new tricks, etc. Far too many to list here, but once you know the terminology you'll find most of them popping up in google results.
Also maybe go take a look at Rob Mensching's old blog when setup isn't just xcopy. Articles there are probably what convinced me that diving in and learning the underlying Windows Installer concepts would pay off in the long run. And it has :)
I've published a blog post on this topic some time ago. You can use the sample from there as a starting point. Take some time to play with it to understand it deep enough. Note that it's not only about WiX, but about Windows Installer as the underlying technology.
We are using Inno Setup and are planning to replace this with WiX. But when evaluating and playing around with WiX, I felt the declarative manner has some limitations compared to programmatic setup solutions.
Moreover I found out that the WiX documentation is rather sparse. So I came across Wix# (WixSharp) which promises to create WiX source code programmatically via script files written in C#.
However we've had some negative experiences with very small companies and even 'one-man-shows'. Therefore I just wanted to ask about your experiences with Wix# (WixSharp) or even other good alternatives out there. Can you report some advantages or limitations?
Wix# looks like an improvingly good bet on the "Will it be around next year" score; see below. And note that Custom Actions are now quite straightforward to build in Wix#.
From this article:
http://www.codeproject.com/Articles/31407/Wix-WixSharp-managed-interface-for-WiX
In July 2014 Wix# was rereleased under more liberal MIT license and it is now hosted on CodePlex.
https://wixsharp.codeplex.com/
In August 2014 UI Extensions to Wix# were released and described in this CodeProject article: "Wix# (WixSharp) UI Extensions".
http://www.codeproject.com/Articles/804584/Wixsharp-WixSharp-UI-Extensions
The fact that new Wix# features are coming out bodes well for the product.
Since Wix# is built on top of WiX and Windows Installer technology, it can only do things that are possible in WiX. When Wix# runs out of gas... WiX can do a lot of things that aren't directly available in the Wix# C# syntax, so you can generally use WiX XML technology directly to bridge the gap. Also see my answer here for additional examples of making Wix# generate the .wxs XML, and then including additional WiX XML code and invoking Candle and Light to build the resulting combined XML into an MSI.
Programatically building an MSI
Below is a quick, non-exhaustive list of WiX and Wix# pros and cons that I have experienced thus far.
WiX/Wix# Pros:
It generates real Windows Installer MSI files.
The uninstall feature is "free"; you automatically get a reliable uninstaller.
The Server Admins in my environment readily accept MSI files for things I as a developer want to install, because they trust the MSI technology and the uninstall feature.
Windows Registry entries are included in the "free" uninstall you get, as long as you create them using WiX or Wix# native syntax and don't merge .reg files--you won't get a registry entry uninstall that way.
WiX/Wix# Cons
Because it's limited to the Windows Installer feature set, some
"procedural" things are harder to do in WiX and Wix#
WiX Pros
Lots of great examples and support resources ("How do I .. in WiX") are available on the Web.
The utilities for harvesting registry entries and putting in XML WiX statements work well.
WiX Cons
As a C# developer, I found WiX XML to be unintuitive to get started
with, working directly with XML files. Wix# and C# made more sense
than WiX at the start.
Wix# Pros
Custom Actions are now simple to implement in Wix#.
Wix# integrates neatly with Visual Studio. I'm currently using it with VS2013.
Wix# and C# made more sense than WiX XML at the start. Better starting point.
Wix# is helping me learn WiX in a more approachable way. Seeing what does and doesn't work in Wix# helps in understanding WiX.
Wix# Cons
Wix# examples are currently a lot harder to come by on the Web. Often it is necessary to research the WiX how-to and then figure out how to apply it to Wix#.
I didn't find an automated path for harvesting registry entries and expressing in WiX# C# code. I translated the .reg file entries manually. It's necessary to have registry entries in Wix# "RegValue(" statements to get the automatic uninstall capability for registry entries.
Note: Developer added this feature in a January 2015 release. I haven't tried it yet.
I will say, doing things in WiX/Wix# that were simple & obvious in procedural installers, like NSIS, and past generation script-based installers (e.g., older Wise editions) often takes extra research and creativity in WiX/Wix#.
Overall, I'm betting on Wix# as a growth technology and a safe bet for current and future use. Worst case, you'd still have your .wxs files, and could change over to using a straight WiX XML approach to building installers, and you'd still be getting value out of the Wix# time investment.
RECENT UPDATES TO THE Wix# Product for Common Installer Tasks
As of January 2015. See: [https://wixsharp.codeplex.com/releases/view/610843][1]
Can now import a .reg registry settings file instead of hand-coding registry class entries
Additional support for Windows Config file modifications
Specific support for Windows Service installations
Support for passing parameter values to Deferred Custom Actions, with all WiX supporting infrastructure properly auto-generated
Support for absolute path in target system directory, with all WiX supporting infrastructure properly auto-generated
WiX has been around for quite a while and has a lot of community support. I've been doing setup (in my spare time :) ) for about 8 years and have never found anything I couldn't reasonable do in WiX.
This is the first time I've seen WixSharp. My first reaction would be how stable is it given it's 0.1.42 at the moment. I'd also be concerned about how much of the MSI schema is actually implemented in WixSharp. It looks interesting, but I'd be more comfortable with an XML file. I don't really see any advantage to do it in C#.
I started to write an installer with WiX. I've spent several days reading blogs and studying tutorials. Last night I couldn't sleep, so I sat down in Fireworks and drew the following picture. That's my understanding so far of how Windows Installer / WiX work. Is there anything wrong? Do you have any suggestion to complete this graph?
http://nestorsulikowski.com/index.php/2009/08/windows-installer-wix/
I'm happy to receive feedback and modify the diagram so that it's useful to more people.
Firstly, forget about WiX for now. Your concern is Windows Installer - WiX is simply a tool to define Windows Installer databases (MSI files). WiX is no different than many other products out there, except for the fact that it doesn't try to mask any Windows Installer concepts for you. InstallShield transparently does a bunch of things that Windows Installer doesn't support via custom actions and the like, WiX forces you to think more about the Windows Installer methodology and way of doing stuff. Windows Installer is what you want to understand, WiX comes afterwards.
Second, get a copy of The Definitive Guide to Windows Installer. This book is an invaluable resource for anyone looking to understand how Windows Installer (MSI) works.
Third, start with the first entry in the UAC in MSI blog posts, and you should be able to get a better grip on things. It is the best documentation I ever read in trying to understand elevation, permissions and all the other stuff that goes with UAC.
The image kind of makes sense, but I think think the UAC series describes the sequences a bit better. Very few people use administrative installs, and if your installer is written properly then there shouldn't be any reason to concern yourself with advertised installations either. They'll just work. Build your installation to work with only the InstallExecuteSequence to begin with, and then add the UI later and you'll have a bulletproof installation that works without much effort.
I cannot create .msi files cause I don't have VS professional, and I want to have much more control over the installer than NSIS or Inno Setup give me.
Things I don't know how to do:
Compress the file(s) into the installation file
Extract the file(s)
Remove the file(s) on uninstallation
Any help would be much appreciated.
I'll stress this point though: I do not want to use an existing tool.
If you really don't want to use something sane like WiX, then you're left with the direct MSFT installer APIs. They're on MSDN starting here : http://msdn.microsoft.com/en-us/library/aa372860%28VS.85%29.aspx, and that's what Microsoft used to use before developing WiX.
Have you heard of WiX? It's open source for creating MSI files.
If you insist on doing this, add a reference to %windir%\system32\msi.dll to your project & the WindowsInstaller namespace will be available to Import.
I don't know what you want to do that's so special that Inno, NSIS or Wix can't do it simply enough, but this isn't going to be any picnic.
Are you sure you have looked at the control that NSIS gives you?
I've not found anything you need to do that cant be done with nsis. The only drawback is the the steep learning curve.
If you can afford it get Installshield. There is a reason the majority of commercial software uses Installshield, It is easy and lets you spend time working on real problems, not worrying about stupid installer minutia.
Otherwise write your own installer and enjoy the pain of reinventing the wheel.
EDIT
You can use ClickOnce installer with the express editions. I've used it before and it is very nice indeed.
Generally when I use ClickOnce when I build a VB.NET program but it has a few downsides. I've never really used anything else, so I'm not sure
what my options are.
Downsides to ClickOnce:
Consists of multiple files - Seems easier to distribute one file than manageing a bunch of file and the downloader to download those files.
You have to build it again for CD installations (for when the end user dosn't have internet)
Program does not end up in Program Files - It ends up hidden away in some application catch folder, making it much harder to shortcut to.
Pros to ClickOnce:
It works. Magically. And it's built
into VisualStudio 2008 express.
Makes it easy to upgrade the
application.
Does Windows Installer do these things as well? I know it dosen't have any of the ClickOnce cons, but It would be nice to know if it also has the ClickOnce pros.
Update:
I ended up using Wix 2 (Wix 3 was available but at the time I did the project, no one had a competent tutorial). It was nice because it supported the three things I (eventually) needed. An optional start-up-with-windows shortcut, a start-up-when-the-installer-is-done option, and three paragraphs of text that my boss thinks will keep uses from clicking the wrong option.
Have you seen WiX yet?
http://wix.sourceforge.net/
It builds windows installers using an XML file and has additional libraries to use if you want to fancify your installers and the like. I'll admit the learning curve for me was medium-high in getting things started, but afterwards I was able to build a second installer without any hassles.
It will handle updates and other items if you so desire, and you can apply folder permissions and the like to the installers. It also gives you greater control on where exactly you want to install files and is compatible with all the standardized Windows folder conventions, so you can specify "PROGRAM_DATA" or something to that effect and the installer knows to put it in C:\Documents and Settings\All Users\Application Data or C:\ProgramData depending on if you're running XP or Vista.
The rumor is that Office 2007 and Visual Studio 2008 used WiX to create their installer, but I haven't been able to verify that anywhere. I do believe is is developed by some Microsoft folks on the inside.
I agree with Joseph, my experience with ClickOnce is its great for the vast majority of projects especially in a corporate environment where it makes build, publish and deployment easy. Implementing the "forced upgrade" to ensure users have the latest version when running is so much easier in ClickOnce, and a main reason for my usage of it.
Issues with ClickOnce: In a corporate environment it has issues with proxy servers and the workarounds are less than ideal. I've had to deploy a few apps in those cases from UNC paths...but you can't do that all the time. Its "sandbox" is great, until you want to find the executable or create a desktop shortcut.
Have not deployed out of 2008 yet so not sure if those issues still exist.
Creating an installer project, with a dependency on your EXE (which in turn depends on whatever it needs) is a fairly straightforward process - but you'll need at least VS Standard Edition for that.
Inside the installer project, you can create custom tasks and dialog steps that allow you to do anything you code up.
What's missing is the auto-upgrade and version-checking magic you get with ClickOnce. You can still build it in, it's just not automatic.
I don't believe there is any easy way to make a Windows Installer project have the ease or upgradability of ClickOnce. I use ClickOnce for all the internal .NET apps I develop (with the exception of Console Apps). I find that in an enterprise environment, the ease of deployment outweighs the lack of flexibility.
ClickOnce can be problematic if you have 3rd party components that need to be installed along with your product. You can skirt this to some extent by creating installers for the components however with ClickOnce deployment you have to create the logic to update said component installers.
I've in a previous life used Wise For Windows Installer to create installation packages. While creating upgrades with it were not automatic like ClickOnce is, they were more precise and less headache filled when it came to other components that needed to be registered/added.