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.
Related
I have a folder containing an exe file and a bunch of other files and a couple other folders. I want to be able to either:
A) Package this all into an installer
or
B) Package the exe and the other files into one singular exe file.
From what I've read, I'm not sure how I'd accomplish either of these with WIX, and I'm 99% sure it's not possible with WIX. Before I dismiss the possibility, I'd like to ask experienced people if I'm right or wrong.
If I can't use WIX, Is there a better alternative?
Thanks for all help.
WiX / Burn: WiX / Burn can indeed make MSI installers or setup.exe wrappers, but it is not trivial to use the toolkit for inexperienced people, and if you have never made a setup before there will be a learning curve. WiX quick start tips.
Burn: Burn is the WiX toolkit's bootstrapper / downloader / chainger tool which allows multiple MSI or setup.exe files to be run in sequence. It allows the creation of a setup.exe which wraps all installer components. Not trivial to learn and use.
Commercial Tools: Quick descriptions of commercial tools Advanced Installer, InstallShield, PACE Suite and some other tools can be found here: Brief descriptions of deployment tools.
And a more elaborate presentation: How to create windows installer.
WIX is highly configurable, and therefore requires some overhead to learn, but it is also very well documented, and gives pretty direct access to windows API's, which are also very well documented.
Packing Existing Files
It is 100% possible to package your files + dependencies into an installer with WIX.
There is a tutorial
Building and Packaging
There is also integration with Visual studio, allowing you to build and run WIX as part of your build.
If you are not using visual studio, that is fine, you can package things with WIX directly, here is
Another tutorial
GUI Installer Creators
If you are completely against the idea of creating your own WIX files and learning the tool set, Advanced installer is a pretty vanilla alternative with a nice GUI
If you really are against making any kind of installer, you can also zip everything up and distribute it that way, can possibly automate this using python.
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#.
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.
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.
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.