I've spent a lot of time fighting with WiX to make an installer that works well with a screen reader. I want the Windows Screen Reader to read the labels and control names out in a sensible and predictable manner, but my findings are that WiX is not very good at producing installers that "sound" right.
Are there best practices or samples that show how an installer, written in WiX, should be structured in order to be fully accessible.
Alternatively, what can I replace WiX with in order to make such an MSI? If I need to replace WiX then I will.
If by “Windows Screen Reader” you mean Narrator don’t waste your time. I’m a screen reader user and Narrator is only good enough to allow you to get enough speech to install a good screen reader. No screen reader users use it on a daily basis so testing with it is pointless. To test with a decent and free screen reader try NVDA found at
http://www.nvda-project.org
I’ve never had issues with installers if they were .msi files; I’ve actually extracted .msi files out of .exe installer packages in order to get passed the custom install code that was not accessible. I had good luck using Visual Studio 2005 to generate accessible installer programs so if your project is a .net app this could be an option.
Related
I have a requirement to create an installer that will allow users to install multiple named instances of our services and application (i.e. Sql Server style).
I have seen that a product called AdvancedInstaller does this and from what I have read this would be achieved through a Bootstrapper capturing the information and streaming it to the MSI. I am assuming here that a Custom UI Burn implementation should be able to do the same, however I cannot find any samples of doing this exactly or on how to do the 'stream' to the MSI.
If I wanted to go this route would I still need to specify instances in my MSI's?
Currently there are separate MSI's for the Windows Services, Application and then a Bundle Bootstrapper EXE that allows the selection of the services to install.
Thanks
MSI has the concept of multiple instance installations using product code changing transforms. These transforms can (but don't have to be) embedded in the MSI. Here's some background reading.
http://blog.iswix.com/search?q=multiple+instance
Read the IS12 then the IS2009. Expect many broken links as Microsoft destroyed their sites. Here are 2020 links.
https://learn.microsoft.com/en-us/windows/win32/msi/installing-multiple-instances-of-products-and-patches
https://learn.microsoft.com/en-us/windows/win32/msi/authoring-multiple-instances-with-instance-transforms
https://learn.microsoft.com/en-us/windows/win32/msi/installing-multiple-instances-with-instance-transforms
When using embedded transforms you are limited to whatever ProductNames you choose when you built them. You could also dynamically generate transforms and apply them.
WiX's standard bootstrapper application doesn't really have much in the way of supporting all the scenarios I talked about in my blog articles. Other tools such as InstallShield and AdvancedInstaller have more.
As much as I like WiX, and MSI for that matter, this is really advanced stuff that takes a long time to understand, develop and test solutions for. You might want to look at using a tool such as InstallShield or Advanced Installer or simply creating a normal straight up MSI that installs a template of an application and then create your own custom instance management tool that allows the user to spin up multiple instances of your application.
I'm an WiX/MSI/InstallShield/DevOps consultant. To be honest, this would not be an inexpensive project if I was to quote it out for a customer.
There are several resources around the web (including here) for migrating InstallShield projects to WiX Toolset, and it's understandable (move from costly product to a free one).
However, I couldn't find anything about the opposite direction - suppose there are several WiX Toolset projects which we want to move into InstallShield (due to issues with WiX licensing). True, we can go ahead and rewrite the projects, but the risk of losing or misinterpreting something is high.
Before we start to develop some sort of automated migration script, I was wondering if it has done before, have anyone ever heard of such a thing?
InstallShield does not have a .wxs importer. However hidden in the File > Open dialog, in the drop down part of the Open button, is the option to Open with Wizard (or, I believe, Open As > Wizard in earlier versions). You can use this to convert a built .msi file into a project file. However if you want it to be a good project file, you will likely still have to perform significant clean up. And be aware that minor upgrades or patches are likely to be difficult or impossible across this tool change.
I don't recall whether this option is available in the InstallShield automation interface, but I think I would prefer to convert and vet each project by hand anyway.
How do I create a localized windows installer package for my WPF application, it has support for 6 languages and I want to have EULA document being localized when user installs the application
I see you tagged Wix and InstallShield, so maybe you are open to try other tools too. Advanced Installer (disclaimer, I work on its development) has in the Professional edition support for multilingual packages.
You just select the languages desired from Translations page, then go to Dialogs page and add a new predefined dialog, select "LicenseAgreementDlg". Advanced Installer will see that you have multiple languages in the package so it will ask you select the EULA file for each language. In roughly 10 minutes you will get your first installer up and running.
I am not quite up to speed on WIX and localization (language support). This online tutorial is a good starting point for you: http://wix.tramontana.co.hu/tutorial/user-interface/do-you-speak-english . Just read through the different User Interface sections.
I don't know which bundling you intend, but in my experience a multi-language setup is less desirable than compiling one MSI file per language. This is easier and faster to compile and work with (very important for large packages), more flexible if you need to bug fix something in a single language, allows you to add new languages easily without full UAT for all languages, and you can deliver the English version as soon as the code is done without waiting several days or weeks for localized files (if any are required).
If you plan to use Windows Installer XML, you can check my answer here. Note that the method is undocumented and not supported by Microsoft, however MS uses it itself and it is working very well.
Just provide a different file for every language transform to the WixVariable WixUILicenseRtf.
I know when I install most legacy installers I seem to get a boat load of shortcuts that I then have to unpin. However I recently tried using the util:InternetShortcut element and I got the opposite. I had to search the start screen to find the items to pin. Strangely the Bing1 showed up and I was able to pin it but the Bing2 shortcut did not show up as available. (Edit: Bing2 is showing up now. Weird)
This is kind of a broad question... but what do I need to know here in a Windows 8 world? I'm working in an enterprise IT environment currently and I'm being asked to come up with a strategy of managing the start screen for users and one of the tools I was researching was MSI based installers.
One of the high level requirements I have is to be able to create shortcuts to websites and configure the icon for the shortcut. This seems to be supported by .url files but not supported by util:InternetShortcut. (Edit: The shortcut seems to auto-sync with the target webpage.)
<util:InternetShortcut Id="test1" Directory="ProgramMenuFolder" Name="Bing1" Target="http://www.bing.com" Type="url"/>
<util:InternetShortcut Id="test2" Directory="ProgramMenuFolder" Name="Bing2" Target="http://www.bing.com" Type="link"/>
Explicitly setting the icon and other pieces of a URL shortcut isn't supported by InternetShortcut today. It would be possible but the WiX custom action code just doesn't implement it today. Probably wouldn't take much effort.
As for default pinning, I expect it's a difference between the way the shortcuts are being created in the WiX custom action vs the way the Windows Installer creates shortcuts. The WiX CA is very, very simple and isn't initializing data in the IPropertyStore which is probably why it is ignored by the Start Screen. Again, not to hard to implement but not available today.
I probably have a strange request.
I have develop a msi to install two softwares. After the EULA a screen with two checkboxes must come and on selection of either or both of these checkboxes the corresponding softwares have to be installed.
I have used to install a single software earlier never for two.
I would be obliged for any leads.
Cohesion & Coupling: Bundling applications together in a single MSI file, may seem like a
good idea. It seems intuitively nice and simple. However, speaking
from real world experience I almost always end up splitting
applications to install via their own MSI files, and I don't like
multi-lingual setups either (true multi-lingual setups are difficult because translated content is typically not ready when marketing and sales push to release the native language version quickly - typically the English version).
The only time it is really safe to deploy applications together is when they are guaranteed to:
Always be used together by end users
Always get updated at the same time
Won't grow substantially in size over time (Localization, New Prerequisites, etc...)
And normally it is impossible to predict any of this. Typically you will get new requirements quickly.
Central Challenge: What will likely take on a release-cycle of its own? (split it right now). Things tend to happen suddenly! Here are some common challenges:
Bug fixes: if only one application has a bug, management will want to deliver only one new MSI and leave application 2 untouched and without the need to do a whole new QA-run for both applications after install. This is to reduce risk and to deliver a smaller update that is also quicker to test and verify. Patching is very complicated, and generally safer for MSI files that are as simple as possible without too many languages, custom actions or GUI constructs.
Localization: suddenly you get a requirement to make application 1 available in Italian, application 2 does not need to be translated. Language support tends to greatly increase the complexity of a setup, not to mention the size of it. Your "nice and simple" MSI has now suddenly gotten complicated to maintain, and sluggish to build. It is also a real pain if you need a single setup, and you translate it in many languages - you won't be able to compile the RTM version until all the language updates are in. I can tell you right now that marketing / sales people will have no concept of holding back the English version until all localized versions are ready.
QA / UAT: if the applications are large, delivering 2 separate MSI files will make it easier to split the testing effort between different QA teams and to deliver new updates via nightly builds etc...
Release schedule: suddenly the release schedule for the applications change - application 1 is now updated every month, whilst application 2 is updated only every six months. If different users use the applications, how do you deliver updates? Build it all in one MSI and give it a new version number only to have application 2 users install the same application over again?
Apply the overall developer principles of cohesion and coupling to deployment packages, and you will save yourself a lot of trouble. If the applications now OR in the future may take on their own life cycle - split their deployment right away. And who can see into the future?
Please note that you generally will wrap multiple MSI files in a bootstrapper so that users still have only one file to relate to, even if the products are installed via separate MSI files.
Wix update: With the advent of Wix to create complex setups it has become easier to build Wix include files that can be compiled into several MSI files. This effectively becomes a more flexible type of merge module. This may simplify the splitting or merging of MSI files in the future. See a discussion of this feature here. One more link.
Sheer setup size: There are some limitations with regards to how many components and files you can have in a single MSI. Some details:
What are the limits for a large MSI package?
Limitations of a Large MSI package
Authoring a Large Package
UPDATE: WiX allows preprocessor constructs and Burn bundles that can be used to split large setups.
Long description here: Wix Installer : Setting component condition property when doing a MSIEXEC admin install at command line (markup towards bottom)
And about different "variable types" in WiX: WiX (Windows Installer Xml), Create universal variables (there are many: precompiler, localization, burn, etc...)
It can be helpful to "decompose" a huge MSI into several related MSI for this reason and other reasons listed above - in order to make maintenance easier (build and compile speed, rebuild of just one of many MSI files, etc...). Finally you should stick to using a single file per component to make upgrading and patching work properly. Several MSI files can be installed in sequence using bootstrappers or launcher applications such as Burn from WiX, or features in commercial tools such as Installshield and Advanced Installer. Here is an answer which touches on this topic. And just trowing in another answer which is a little bit similar.
Links:
Installing SQL Server 2014 Express as a prerequisite in boostrapper
Windows installer has a concept of "features" which can be selected for installation or omitted. If you have already created a working installer, then you have at least one <Feature> element in your WIX files.
Simply create multiple <Feature> elements and then use <UIRef Id="WixUI_Mondo" /> or <UIRef Id="WixUI_FeatureTree" /> to allow the user to choose which features he wants to install.
You cannot install multiple applications from a single MSI. Even if you figure out a way to do this you really should not.
Instead have separate MSIs for each app and use a bootstrapper to install both. E.g. you can use Inno Setup to generate a self-contained bootstrapper exe which installs both MSIs (and any pre-requisites as well).
BTW, Wix does not handle creating bootstrappers so you need to use it in conjunction with another tool.
You can do nested msi pre windows installer 4.
But you shouldnt anyway it was deprecated for a reason.
The replacement api is to call msiembeddedui and create a transaction chainer.
You can create multiple MSI's then bundle them into 1 containing MSI. The "parent" MSI allows you to choose which application to install then just runs that MSI.
If you really want 2 applications then there are non-MSI installer builders (like NSIS) that let you do that, but you have to do all the work yourself.