I am currently creating an installer for my software. I decided to use WIX for it, because I read on stackoverflow that while it has a steep learning curve, it is the most versatile tool to create .msi installers.
I'm trying to create a very simple one screen installer, and I'm happy with the results so far, but some of the controls just look really outdated.
The sunken text edit doesn't really match the look and feel of Windows 10. What bothers me more is the file browsing dialog, though.
I know that I can change the logo, but the icons and everything just look like they're coming from Windows 98. Since WIX seems to be a widely adopted option for creating Windows installers, I thought there must be a solution out there to create a more modern look and feel, but I wasn't able to find anything.
Do I have to live with the outdated look? If so, do you have a better alternative for creating Windows installers (.msi not required)?
Custom GUI: Maybe I can add to Phil's answer that the WiX installer itself uses such a custom Burn GUI. You obviously have the WiX installer already, but here is a link to the WiX 3 installert for other readers.
Burn: Just to clarify: Burn is part of WiX - it is a bootstrapper / sequencer / downloader tool designed to help you run several MSI files or setup.exe binaries in sequence. Hence it allows you to also install prerequisites. The fact that it allows an external GUI is just another aspect of its primary function: to install all the setups and components you need - in the right order.
MsiSetExternalUI: For the record: the underlying feature in Windows Installer itself that allows an external GUI to be used is the function: MsiSetExternalUI? I think Installshield - one of the leading commercial tools for creating Windows setups - provides some more modern GUI features as well - using this external GUI approach, but I don't have a full overview.
Some Burn samples: There are many samples available on github.com for how to make Burn bundles with WiX. Here is a nice, first sample of what Burn can do: https://github.com/frederiksen/Classic-WiX-Burn-Theme. This shows how you can make a simple Burn GUI that has a more "modern feel".
There are many other resources available. Here are a few I would recommend:
WiX Burn XML Markup Sample - "Hello WiX Burn (on steroids)".
WiX Burn Information & Simple Markup Sample
"Hello WiX Burn" on top.
Lots of links for further information below. See section "Some Burn Sample Links".
Burn has a standard GUI available - which is more modern than the normal MSI GUI. But you can also implement the whole GUI yourself - as Phil states in his answer. Here are a couple of links on the subject:
Write your own WiX Burn setup GUI application (advanced)
https://github.com/rstropek/Samples/tree/master/WiXSamples/CustomBurnUI
More WiX samples for other aspects of WiX found a level or two higher
MSI GUI: The actual MSI files themselves can also have a customized GUI. Here is an old answer on customized MSI GUI.
To be clear: the Burn Setup.exe has one GUI and the actual MSI files included can have their own GUI embedded. The embedded GUI in MSI files can be suppressed via Burn (also by msiexec.exe install commands).
Some Links:
Uncommon UI layout for Windows installer for Techsmith Snagit
WiX root feature without Treelines
msiexec.exe to stdout
Wix - Choice of UI based on property
You get a basic UI with Windows Installer, and that's mainly because it comes from 1998 (pre .NET) and could not assume that anything (.NET, C++) was on the system other than the bare bones of Windows. And obviously it's not been modernized.
The standard way to do this is to build your own UI using Burn, supplying your own UI to contain the standard data that the install provides as it progresses. If you do a search for "burn ui wix" you'll find examples of how to provide that framework, such as this one:
https://frozencloud.wordpress.com/2016/05/03/creating-a-custom-ui-installer-with-wix-burn-bootstrapper/
It gets complicated because you need to deal with all aspects of the UI, including file-in-use dialogs, that browse dialog, and so on. There may be some complete examples somewhere if you search for examples.
Related
What are the differences between COM msi.dll WindowsInstaller and Microsoft.Deployment.WindowsInstaller?
I know one exists in %WINDIR%\system32\msi.dll and the other exists in Visual Studio's reference assemblies list.
I know the implementation of the Installer objects are completely different.
Why are there two different implementation of WindowsInstaller? and why are they called the same?
MSI API: The Windows Installer API is quite old and is implemented as Win32 C/C++ functions and a layer of COM automation on top (which you can use VBScript and many other languages to access). This is all implemented in the %WINDIR%\system32\msi.dll file (and whatever other support files are involved - I am not quite sure - there is also msiexec.exe of course - the actual installation engine and command line tool to install and configure MSI packages and msihnd.dll - and a few more I think).
DTF (Deployment Tools Foundation): As the .NET framework and managed code came of age, the use of COM and Win32 functions was kind of clunky and the Deployment Tools Foundation kit - also known as DTF was implemented to help use the MSI API with managed code. The file: Microsoft.Deployment.WindowsInstaller.dll is one of the files delivered as part of DTF and the most commonly used one. The WiX toolkit now installs DTF as part of its normal installation. Please check the links below.
Links:
A sample of DTF code and more details (recommended - see same page for COM).
The various APIs for MSI files.
Note, there are also some WMI functions.
What's the best way to distribute a windows application:
Which format should i use to distribute the application, an exe-file
or a zip-file?
Should i sign the application?
Are there any other points i should take into account?
I'm going to create an installer for the application using innosetup. The application is made using node-webkit.
(I'm not a Windows user, but) MSI package is better than both an exe-file and a zip-file. The freedom to choose interactive or unattended [un]installation, and the ability to handle dependencies and upgrades are enough to make it the best option. WiX makes MSI creation easier -- give it a try.
So long as the application deploys - it makes no functional difference the data format you choose to distribute in.
I will speak from a user perspective as opposed to a technical one here; please include a CLEARLY LABELED installer (MSI is the best for this; but if it is .exe, or .bat or whatever, label it as "Installer" or "Click to install" or something similar) and a useful readme, if you do choose to distribute in a .zip.
It all depends on what the exe entails. If it's just a simple .NET executable and it's self contained, all you need is the exe in a zip (pending it's < .NET 2.0 which is included). Each newer succeeding version of Windows has .NET runtimes built into the OS incrementing all the way up to 4.5 or 5.0?
So if you have the latest Windows, and it has the .NET 4.5 libraries on it, all you need is essentially the executable. However if it is an older OS, you may need to bundle or link the runtimes needed. Some apps need third party components installed and other DLL's. In which case your best bet would be to use a third party tool like Install Shield or Wise, or Orca, where you can customize the install and install third party components like SQL Server Personal, Oracle Personal or mySQL Database or Crystal report components.
Also if NTFS permissions and network permissions are required or registry values are required you'll need to script it with Wise, InstallShield, etc, and require elevated permissions. Microsoft also has some built in Deploy Once(?) tools that allows this to be done via the web, or network path or executable.
It all depends on the complexity of your exe, how much it effects your system etc. I've seen apps that require even firewall exceptions, etc. If you are in a corporate environment and have a domain you can deploy using SCCM/SMS or UniCenter. Like I said it all depends on complexity, and scope.
If it's a simple .NET 2.0 app, then all you need is the exe in a zip. The best way would be to copy the exe to a few different systems and test it.
MSI's are inherently able to execute from shell or run/explorer. Also you are allowed to compile your install into a self contained executable.
Bottom line, it all depends on your app :)
I have a need to describe deployments/installs, and possibly uninstalls as well - but I don't want to use Windows Installer. At the same time, I don't want to completely re-invent the wheel.
It occurred to me that I could perhaps use the WIX declarative schema, but create my own "WIX interpreter" that will perform the install / uninstall steps (as described by a target WIX xml document) without using the windows installer.
It would be nice to go a step further, so that I achieve a cross-platform (Linux, MAC) installer-interpreter. Of course WIX did not have Linux and MAC in mind. In which case I either add xml namespaces to extend WIX, or use some other industry format (that I am yet unaware of).
But perhaps I'm stretching too far. At the very least it would be nice to have a WIX interpreter or a WIX install executable that does not create any records in the windows installer. It need not fulfill every capability of the windows installer. I'd just like to see some basic capabilities fulfilled.
Does anyone know of such a thing, so I can save myself the effort of making it myself?
Each operating system has their own means of managing installed packages.
That means that if you implement your own package management scheme, it will not integrate well with the current operating system standard. This has a number of very bad side effects, mainly the people maintaining the operating system through standard tools run a high risk of not knowing your software was installed because the standard tool didn't report it was installed.
Microsoft's installer is quite different than many other installers, and it supports extension via programming, which is typically done in the VB C++ language. Also, Microsoft supports the mixing of configuration and installation, while many other package managers see these as different functions to be performed at different times. Finally, Microsoft attempts to ask for the configuration information PRIOR to installation, while installers that separate out the role of configuration and installation typically request that the configuration be done AFTER the program is installed.
In truth, there are way too many different "assumptions" about what constitutes installation, and when / how to do said items, and what tools can be expected on particular platforms to easily merge "all items" into a single multiple-system installation tool without the vendors coordinating a little bit to allow for some compatibility.
I want to create an installer for my project, primarily to handle the external dependencies which are starting to grow in number.
The problem is most of these components seem to be distributed in different manners, so I need an installer that can cope with all the following. Ive looked at various things around, however many dont seem to cover all the things I need (like how to install directX using a Visual Studio setup project...), or dont even create a proper windows installer (eg .msi).
Copy all my apps files to the target directory
Create start menu and desktop shortcuts
Install direct x (ie call dxsetup.exe /silent)
Install the VC9 CRT redist (seems to be a "merge module" looking at msdn whatever that is...)
Only requires administrative rights if one of the following is true
DirectX and/or the VC9 CRT is not already present, or needs updating
Installing for all users
Installing to a directory the user doesnt have write permission for
Can roll back everything if installation is aborted before completion
Generates an uninstaller as well as an installer
Ensures the user accepts all required EULA's (my one, VC9 Redist, DirectX, etc)
For example I got the VS2008 Setp Project working for my app files and the VC9 CRT, however I dont see anyway to tell it to just run dxsetup.exe with the /silent argument and NOT extract it and all the other dx installer to the app directory or something...
EDIT:
Also it would be really nice if I could have a unified installer for x86 and x86-64, which installers the correct components (eg myapp_x86.exe or myapp_x64.exe) depending on if the OS is 64bit or not.
EDIT2:
Forgot to mention but either a free or low cost solution would be welcome as well, since I need a solution for some of my smaller personal stuff as well.
WiX is what you want. You'll want to read through the v3 documentation and examples, as it is not a simple thing to use. Once you get going, you'll have follow-up questions which you should post as new questions.
See also the WiX tutorial, but keep in mind it refers to v2, and a lot of it is out-of-date or obsolete in v3.
If you can afford it, Installshield does all this very well and professionally. It will include the merge file and seamlessly install as well. Installshield has its quirks, but it is incredibly easy to use and robust. Once you write your app, you don't want to think a lot about the installer.
Some nice features I liked
Creates patch installs by diff'ing the source so you can distribute patches with a small size.
Create upgrades that update the registry and version number of your app. Prevents older versions from being installed.
Creates an nice uninstaller.
It's Easy to add merge modules.
Scriptible if you need it to be, GUI if not (most of the time you don't need to script a thing).
If you can't afford that, go with NSIS. It is very powerful and well used, but prepared to write code in a text editor.
Follow these STeps
I want to create a Windows Installer, the 1st step I want it to call another installer (will install dependent components of my application), and the 2nd step I want to install my own application. I want to do all tasks in one installation process, and I have the dependent component installation package at hand (an exe file).
Any good tools or samples to refer to? I prefer to use VSTS or Microsoft or open source easy to use tools. :-)
thanks in advance,
George
You might want to take a look at the Microsoft Bootstrapper, assuming the dependent components are libraries such as .NET or similar then it's fairly straightforward.
If you want to create a Windows Installer (MSI) package then take a look at Windows Installer XML (WiX). But you'll want to get your head around how MSI works first. WiX is really simple once you understand Windows Installer, but trying to learn both at once can be rather confusing.
For a basic, copy some files, extract/run some stuff, type installer then NSIS is fairly straightforward scripting and you can pick that up in a day or so.
Nsis with this modification.
Update: It seems that nesting MSI installation is somewhat possible. However it requires some tweaking using tools from the Windows Installer SDK and has a number of drawbacks.
The following article has the details:
How to create a nested .msi package
Microsoft recommends not to use this feature (see this related answer and point 20 in this list).
However, you might also want to look at different install systems such as NSIS or create a bootstrapper that installs the dependencies prior to setup.
You could look at Inno Setup. It creates exe installers, as opposed to MSIs. It has a pascal-based scripting language, so is pretty flexible.
It's free and pretty easy to use.
If your existing installer doesn't use the MSI technology, you could use WiX to create an MSI and launch the existing installer via a custom action. I've done this in the past.
WiX is open source.
yes it would be very easy if you do it using Inno Setup, but with a slight difference..
You will have to perform step 2 first and then step 1.
Try using AutoHotkey(scripting) for checking the existence of any process in the background that verifies the installation of a particular software.
Check out iexpress on windows systems. In just a few minutes you can create an installer that can call as many installers as you like.