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.
Related
I am using WiX for make installer for any product. But I don't want to use default UI dialog which is using in WiX. How to improvise UI of a installer ? Is there any tool for designing UI for a installer with highly customize ?
Rich GUI is done in bootstrapper (aka. chainer). Chainers are made in tool called Burn (B is for bootstrap). I'm not all that familiar with it, but it was supposed to replace all the GUI available by Windows Installer that you can set in .msi files. This GUI is restrictive, and suitable only for simplest tasks, so the idea is to build .msi only as a database file that is to be consumed by Windows Installer to actually install something, and transfer all the GUI to bootstrapper.
The only thing I've come across is WixEdit, although it seems buggy and may have been abandoned. Still, it allows you to do basic UI design of the WiX dialogs.
I recently came across something called Wix#. It lets you make custom dialogs using a Winforms-like designer.
I know it's 9 years later, but if it helps, great.
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 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.