I read WiX documentation.
Time of time in the WiX documentation I see the phrase "Any Attribute (namespace='##other' processContents='lax') Extensibility point in the WiX XML Schema. Schema extensions can register additional attributes at this point in the schema". For example i see it here.
I don't understand this phrase and in particular what is specified in the brackets. I will be grateful for clarification.
The referenced subphrase namespace='##other' processContents='lax' is XSD terminology; see questions on ##other and processContents for more details on what they directly mean.
In this context, this allows you to insert qualified (i.e. namespaced) attributes into a WiX element and still validate the resulting XML document. Most WiX elements allow both attributes and child elements of this nature. They are used, as the text suggests, to allow for extensions to WiX that process these attributes and elements as part of a build step. You can create your own extensions to automate or simplify specialized tasks that the WiX team doesn't implement in core.
Related
I several times had trouble finding information about valid elements in csproj files (.NET Core). Especially ItemGroup with Content and Include/Exclude/Update/CopyToPublishDirectory attributes.
Also I am interested in "None Include=..." elements.
Is there any offical reference for all this?
At least I could only find a few SO posts.
Update
in the meantime I found this upgrade guide (project.json -> csproj) by Nate McMaster which contains a few examples for Content and None but is far from a reference.
https://learn.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj
I have also had difficulty finding good reference information about this
This list of well known item metadata properties may help
https://msdn.microsoft.com/en-us/library/ms164313.aspx
However for include / exclude attributes (as against properties)
try this msdn link
https://msdn.microsoft.com/en-us/library/ms171453.aspx
At a pinch I have often written a custom task which takes an itemgroup and iterates metadata - though it's worth noting the difference between metadata (such as the Identity property), and attributes such as include exclude, which are fixed, and explained in the second msdn link
What is the correct syntax for giving guids for components in the wxs file for WIX?
In most samples I found
Guid="00AD2D6E-BF8A-4EA8-BE9A-57380DECD0E6"
but in some samples I found
Guid="{00AD2D6E-BF8A-4EA8-BE9A-57380DECD0E6}"
I would prefer the second version, because this is directly generated by the GuidGen tool. But is it correct?
Component GUIDs: On Component GUIDs and when they should change: Change my component GUID in wix?
Auto-guids and default attribute values
In addition to Bob Arnson's advice:
Recent versions of Wix allows GUIDs to be auto-generated for several things, most significantly component GUIDs. It also covers package-, product- and patch-codes.
It also allows skipping some, or even most attribute values from explicit definition since most of them can be defaulted to predictable values. See code snippet below for an example.
Auto generating component GUIDs is possible because component GUIDs should remain the same once created unless the installation path is changed - this is described in this stackoverflow post. Accordingly Wix calculates a GUID based on the target path and other factors.
Product, package and patch code can generally be randomly created as they are simply supposed to be unique.
Note that an upgrade code is special - it should not be auto generated. It is generally desired to remain stable between releases and even between different editions and languages of the software in some cases - this depends on application design and how editions are implemented (you can use different upgrade codes and still implement a major upgrade, but the upgrade table gets complicated).
As a rule of thumb upgrade code identifies a "family of related products", product code identifies an installed edition of some kind and package code identifies a unique file. Two files with the same package code is by definition treated as the same file (this can case mysterious errors - make sure to always auto-generate the package code).
Check the Wix documentation for details on the auto-generated GUIDs.
Simplified Wix XML Source Files
Used correctly these auto-generated GUIDs can significantly simplify your Wix source files:
<!-- Sample guid below, do not copy paste -->
<Component Id="File.dll" Guid="{12345678-1234-1234-1234-123456789ABC}">
<File Id="File.dll" Name="File.dll" KeyPath="yes" Source="..\File.dll" />
</Component>
versus
<Component>
<File Source="..\File.dll" />
</Component>
Taken together, the combination of auto-guids and the default attribute values yield Wix XML source files that are shorter and easier to read due to the removal of a lot of "noise" - this arguably makes them less error prone:
terser source files are easier to maintain and less error prone since it is easier to see what changes with diff tools and the less text exists, the less errors can hide
along the same lines, copy and paste of existing XML elements can cause difficult to find errors due to incomplete update of all attributes. Fewer attributes, fewer errors. I copy and paste a lot when using Wix "manually" (not using XML generators). Note that most errors are picked up by the Wix compiler and linker, but errors can still hide.
any changes to the default values can then be picked up auto-magically from the compiler and the linker making them propagate easier to MSI files everywhere that have been built with Wix. It is always good to keep your source files as simple as possible, but no simpler
overridden defaults also stand out in the source file, and you can add comments to explain why the non-default value is needed
Other Wix tips here, though the article may be a bit dated.
The WiX compiler converts either form to the form that Windows Installer expects (with braces and uppercase letters).
I've used both of them and both seem to work perfectly fine.
I am someone with little to no experience with wix and I am trying to support Windows also for the component I am responsible for. I am trying to create merge module for a set of files that my product generates. These files exist in numerous sub directories. I was wondering how I can create a single component ID for all the files in the entire tree. I am not worried about minor upgrades as that is something I am not going to be doing. I am trying to avoid generating numerous GUIDs for each of the file.
Also is there any way I can change the name of the root directory I want the files to be installed. Currently, in our build system the files I want to install end up in a directory name "install". In the wxs file generated by heat it comes up as install. I was wondering if I could change it to the actual product name instead of "install".
Use one file per component - this avoids all sorts of problems (except .NET assemblies spanning multiple files). See the following thread: One file per component or several files per component?
Wix is a great framework for creating installers, but it has a steep learning curve. I strongly recommend you read a few sections of this great, online tutorial: https://www.firegiant.com/wix/tutorial/
If you are a "sample based tinkerer", you can find an even quicker, sample based tour in this article: http://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with
Wix is hands-on. Just focus on the samples, and focus on getting the components created and a major upgrade set up:
How to implement WiX installer upgrade? (modern, convenience way)
How to get WiX major upgrade working? (legacy way - more flexible, less convenient)
http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html
Once you got that running the rest of the details fall into place by reading the documentation for whatever feature you need. Using Visual Studio / Votive with intellisense ensures that you can learn as you go with features such as shortcuts, ini files, xml files, dialogs, etc...
Another top tip is to use dark.exe (part of the Wix toolkit) to decompile existing MSI files. This yields Wix XML with code you can copy and paste into your own Wix files. I use other MSI tools to compile such MSI files, and then copy the sections I need into my Wix file - just to speed up the process of creating the Wix XML. Studying the decompiled XML is very educational - a real time saver.
UPDATE, May 2021: Some more links:
WiX Quick Start - Very long version
WiX Quick Start - Short version
If all the files are going to the same destination folder, then you can create one single COMPONENT with all the FILE within it. There is nothing stopping you to do that. You can then just create one GUID for that component. Also read these answers which talks about the advantages vs disadvantages of one component vs multiple components before you implement it: Answer1 Answer2. To Summarize:
You will have trouble with minor upgrades/repairs. If a component is
being updated, only the file designated as the KEYPATH is checked to see if
it is out of date: if it is up to date, all the others are ignored.
You'll also have difficulty if you want to add or remove files from each
component. Once released, a component is immutable (in terms of what files
are in it). The only way to update it without breaking component rules would
be to effectively remove and install the a new version of the MSI.
Understanding the component rules is key in Windows Installer and one file
per component makes the component rules easier to work with, which is why it
is the recommendation of many people here.
LINK
The root directory name can be changed by modifying the "Name" property for the DIRECTORY element.
Can somebody please point me to a reference for the syntax of the expression language used in csproj / vbproj files within Visual Studio ? I've been seeing usages like the following :
<FilesForPackagingFromProject Include="%(CustomFiles.Identity)">
... and I'm trying to understand the '.Identity' bit.
The Identity bit is one of many MSBuild Well-known Item Metadata. It is essentialy metadata of msbuild Items. You can use the metadata to Transform Item Types.
This question How do you include additional files using VS2010 web deployment packages? doesn't directly address your question but the most popular answer has loads of useful information and provides a clue as to what the % sign means.
<_CustomFiles Include="..\Extra Files\**\*" />
<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
I think the _CustomFiles tag creates a link to an external file, then %(_CustomFiles.Identity) refers to an element within that external file.
UPDATE:
NO! This is not right. The % expression gives a scalar value. The _CustomFiles is an Item and the .Identity part of the syntax refers to well-known metadata as explained by Marcos in the accepted answer.
I'm using WiX's admin-image-style patch creation, but the resulting patch contains extra files that I don't want to include. My understanding of WiX patching is that it is "inclusive" by default -- that is, that you choose what to include, rather than exclude. I found this comment by Peter Marcu indicating that admin patching is the way to go if you want to exclude specific files. I have a couple of questions:
He mentions that when you do an admin install each component is put into its own fragment -- how does this work?
He also says you have to use patch families (note the plural) -- what is the accepted practice for this? Do I need a ComponentRef for every component I'm including, given that they are all in individual fragments, as in (1)?
The default behavior is to include all differences. If you don't want all, then you need to specify them individually. When you're using admin image patching, WiX creates fragments as granular as possible, so yes, you need individual ComponentRefs, BinaryRefs, etc.