Wix-commits Digest, Vol 11, Issue 31

Каталог рекламы и объявлений

Ящик для предложений: sales@blogslov.ru

Send Wix-commits mailing list submissions to
wix-commits@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-commits
or, via email, send a message with subject or body 'help' to
wix-commits-request@lists.sourceforge.net

You can reach the person managing the list at
wix-commits-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wix-commits digest..."

Today's Topics:

1. wix/src/chm/html extension_development.htm, NONE, 1.1
light_usage.htm, NONE, 1.1 lit.htm, NONE, 1.1 lit_usage.htm,
NONE, 1.1 osinfo.htm, NONE, 1.1 votive_development.htm, NONE, 1.1
votive_item_templates.htm, NONE, 1.1
votive_project_references.htm, NONE, 1.1
votive_project_templates.htm, NONE, 1.1
votive_property_pages.htm, NONE, 1.1 votive_wix_references.htm,
NONE, 1.1 wixvsextension.htm, NONE, 1.1 wxl.htm, NONE, 1.1
WixUI_dialog_library.htm, 1.4, 1.5 authoring_custom_actions.htm,
1.3, 1.4 authoring_merge_modules.htm, 1.3, 1.4 extensions.htm,
1.1, 1.2 light.htm, 1.1, 1.2 patch_building.htm, 1.3, 1.4
perfmon.htm, 1.3, 1.4 preprocessor.htm, 1.1, 1.2 qtexec.htm, 1.1,
1.2 robmen_20040405.htm, 1.3, 1.4 robmen_20040511.htm, 1.3, 1.4
robmen_20041130.htm, 1.5, 1.6 standard_customactions.htm, 1.2,
1.3 votive.htm, 1.1, 1.2 wxs.htm, 1.1, 1.2 (Rob Mensching)

----------------------------------------------------------------------

Message: 1
Date: Wed, 27 Jun 2007 05:36:16 +0000
From: Rob Mensching
Subject: [WiX-commits] wix/src/chm/html extension_development.htm,
NONE, 1.1 light_usage.htm, NONE, 1.1 lit.htm, NONE, 1.1 lit_usage.htm,
NONE, 1.1 osinfo.htm, NONE, 1.1 votive_development.htm, NONE, 1.1
votive_item_templates.htm, NONE, 1.1 votive_project_references.htm,
NONE, 1.1 votive_project_templates.htm, NONE, 1.1
votive_property_pages.htm, NONE, 1.1 votive_wix_references.htm, NONE,
1.1 wixvsextension.htm, NONE, 1.1 wxl.htm, NONE, 1.1
WixUI_dialog_library.htm, 1.4, 1.5 authoring_custom_actions.htm, 1.3,
1.4 authoring_merge_modules.htm, 1.3, 1.4 extensions.htm, 1.1, 1.2
light.htm, 1.1, 1.2 patch_building.htm, 1.3, 1.4 perfmon.htm, 1.3, 1.4
preprocessor.htm, 1.1, 1.2 qtexec.htm, 1.1, 1.2 robmen_20040405.htm,
1.3, 1.4 robmen_20040511.htm, 1.3, 1.4 robmen_20041130.htm, 1.5, 1.6
standard_customactions.htm, 1.2, 1.3 votive.htm, 1.1, 1.2 wxs.htm,
1.1, 1.2
To: wix-commits@lists.sourceforge.net
Message-ID:

Update of /cvsroot/wix/wix/src/chm/html
In directory sc8-pr-cvs9.sourceforge.net:/tmp/cvs-serv1332/src/chm/html

Modified Files:
WixUI_dialog_library.htm authoring_custom_actions.htm
authoring_merge_modules.htm extensions.htm light.htm
patch_building.htm perfmon.htm preprocessor.htm qtexec.htm
robmen_20040405.htm robmen_20040511.htm robmen_20041130.htm
standard_customactions.htm votive.htm wxs.htm
Added Files:
extension_development.htm light_usage.htm lit.htm
lit_usage.htm osinfo.htm votive_development.htm
votive_item_templates.htm votive_project_references.htm
votive_project_templates.htm votive_property_pages.htm
votive_wix_references.htm wixvsextension.htm wxl.htm
Log Message:
Benxing: Number of patch related bug fix
*Update FeatureComponent table when ComponentRef in the selected PatchFamily
*File Sequence problem

PMarcu: Allowing extension attributes on DirectoryRef and PropertyRef
Adding extension attributes to the VSExtension Refs

PMarcu: Adding UIRef and DirectoryRef to possible PatchFamily Children
Allowing extension attributes on CustomAction elements.

JRock: Added support for setting pre- and post-build event command lines via a
property page in Votive. This gets me one step closer to restoring the
inter-project variables that we had in V2 but had to pull in V3 to get
it out the door (e.g. $(var.MyProject.TargetPath)).

JRock: Added support for SolutionX variables in the wix.targets file. So, you
can now use $(var.SolutionDir) in your .wxs files and have the variables
automatically added to the preprocessor definitions when building with
wix.targets and MSBuild.

Benxing: Regardless of differences in the MST, we will compare underlying files before
copying data into the patch. Extensions can override CompareFiles to provide
custom file diffing behavior.

AaronSte: Updating Heat to use HKCU instead of HKLM when harvesting registry
information on Windows Vista to avoid UAC issues

PMarcu: Making XsdStitch only output a single prefix for each extension namespace.

Benxing: Fixing null reference exception in the binder when the file table is empty.

RobMen: Default File/@Name to File/@Id.

MikeHo: Fix bug with Setup.exe when trying to install and TEMP and AppData
folders are not on same drive, setup fails

MikeHo: Add fallback to Caching the MSI.

RobMen: SFBUG:1680666 - Correctly modularize RemoveIniFile.DirProperites.

PMarcu: Removing FragmentRef's

AaronSte: SFBUG:1675664 - Marking ComboBox value attribute as localizable.

PMarcu: Adding BinaryRef as a child of PatchFamily.

Benxing: Give warning when removing component from feature during the patch build.

PMarcu: Changing namespace keys in the VSExtension help tables to not be modularized.

PMarcu: Adding some targeted checks to patch transforms to catch possible error
conditions as early as possible.

AaronSte: Adding Visual Studio Codename Orcas detection properties.

AaronSte: SFBUG:1687207 - Update Heat so DllRegisterServer captures will work
on Windows Vista from an elevated cmd prompt.

PMarcu: Fix for DocCompiler to handle ref attributes in attribute definitions under
elements.

BobArnso: Resize and combine some controls to better fit localized strings
(affects all UI sets, dialogs UserExit, OutOfRbDiskDlg, OutOfDiskDlg)

Benxing: Skipping unreal tables when binding transforms to improve patch build
perfomance.
Adding active substorage into binder extension to give the ability to
access corresponding transform information.

JRock: SFBUG:1673425 - Cannot access the VS menu using the alt key
SFBUG:1576283 - Unable to enter 'c' or 'm' in proj properties screen fields
SFBUG:1570392 - Project Designer - Index was outside the bounds of the array
SFBUG:1566296 - Setting 'Cultures' field in project properties has no effect
SFBUG:1576287 - Modifying project properties does not force rebuild

Benxing: Ignore rows without section id in ReduceTransform.

MikeHo: Allow for multiple files to be extracted from chainer.

AaronSte: Adding Visual Studio Team Test project system detection properties.

FGrohn: Support for PubCA in WiX v3.

HeathS: Added extension support to the Validator.
Exposed extension support for the Validator through light.exe.
Exposed extension support for the Validator through smoke.exe.
Exposed multiple .cub file support through smoke.exe.

HeathS: Exposed multiple .cub file support through light.exe.
Added a test for the Validator and multiple .cub support in light.exe.

MikeHo: Add error messages for Windows Installer service can't start or Install
blocked by system policy

BobArnso: Add WixQueryOsInfo CA to detect system suite info and "special
folders" as properties over and above the MSI set

BobArnso: Default to removing library rows from decompiled output in
WixUtilExtension

PMarcu: Refactoring patch buld system to use Pyro instead of Light for filtering
and binding. Other target patch specific bug fixes are in the mix as well.

PMarcu: Adding more command line options to Pyro, specifically the ones that
provide settings for the binder.

PMarcu: Adding error and warning preprocessor instructions.

PMarcu: Fixing an exception thrown when Dark is run and no extensions are defined
in the config file or the config file is absent.
Also, bug where Customtable columns that are not foreign keys have the
keytable attribute defined on the column as keytable="". This results in
an invalid table reference to "".

PMarcu: Switching order on Pyro commandline.

Jordanf: Adding support to WixUnit for Pyro. Fixing the qtest patch.minorupgrade
to use Pyro.

BrianRe: Added code to detect a namespace prefix that is already in use and if
so it will append it with its' position within the "duplicates" for
that specific prefix; eg. sql, sql2, sql3, and so on.

RobMen: Add support for PerformanceCounters (including managed code).

FGrohn: Added COM+ and MSMQ extensions to the zip file.

FGrohn: Move to Windows Vista SDK.

JRock: SFBUG:1566807 - Display full version in about dialog.
SFBUG:1697089 - MSBuild WiX taskscannot resolve WiX tool paths automatically
SFBUG:1689830 - Error when using Wix3 when not installed on C drive

Benxing: Handle Sequence tables when building the patch.
Don't allow empty patch.

HeathS: Added an extension for installing PowerShell snap-ins.

PMarcu: Adding Melt as a tool to decompile MSM's to ComponentGroups.

PMarcu: Adding warning for when a non keypath file is updated and the keypath file
of that component is not.

Benxing: Adding information into _SummaryInformation table for patch build.

PMarcu: Adding a check to assure no duplicate fragment Id's exist.

JKuhne: Fixing a GC issue with the Validator. (Locals are rooted until last reference, not
end of scope.)

BobArnso: Add DiskId attribute to Directory and DirectoryRef to provide default
DiskId for contained components and files.

MikeHo: Fix language matching in Setup.exe

PMarcu: Making sdut and tsa defaults when passing xo to light.exe

AaronSte: Adding more CSIDL values to WixQueryOsDirs custom action

RobMen: Reverse integrate WiX v2 CustomAction fixes.

BobArnso: Add element-extensibility points to Directory and DirectoryRef.

Jordanf: Add a new test for preprocessor .

Mikeho: Add NewFolder UIText element.

AaronSte: Adding custom actions to run devenv.exe /InstallVSTemplates to the
WixVSExtension

BobArnso: Pass directory ID to Directory and DirectoryRef extension elements.

RobMen: Introducing smart-cabbing.

RobMen: SFBUG:1707259 - fix nasty memory violation
HeathS: Added patch-specific property to identify client patches and
if they can be removed.

Mikeho: Fix manifests for setupbld.exe/setup.exe

JordanF: Add the -update option to automatically update a test. Make MSI/MSI
validation explicit in the tests.

JRock: Adding back project references to Votive V3! Actually, I'm adding them
to the wix.targets MSBuild file to be exact. Votive uses it, but you get
the goodness without using Votive also. Basically, this is the feature
where if you reference other projects in your Visual Studio solution,
you can reference the output of those projects from within your wixproj
project. For example, $(var.MyCSharpApp.TargetPath). This will work for
any managed project in Visual Studio (at least it does for VC#, VB, and
VC++ managed). You have to build from within Visual Studio or from the
command line. If you build just the .wixproj, then you won't get the
project variables defined.

SFBUG:1585281 - Add solution and project variables back to Votive v3

MikeHo: Fix support for more than 10 MSIs/MSTs

JRock: SFBUG:1588291 - Support response files for MSBuild candle/light/lit
tasks

BobArnso: Have heat generate a default ComponentGroup when harvesting
directories in a fragment.

JRock: SFBUG:1717966 - Solution Build Issues (build 2911)
When a wixproj is the only thing in the solution, the SolutionX
variables aren't defined when building within Visual Studio. This
is because normally C#/VB define these variables for us. The fix
is to define them ourself.

HeathS: SFBUG:1716160 - ICE03 string overflow error, xmlFile

RobMen: SFBUG:1716160 - fix string overflow error for XmlConfig

BrianRe: Fixing wix.xsd to use W3C recognized regular expressions.

PMarcu: Defaulting Media\@Source to a form of the patchId if not specified
when Media is a child of a patch.

RobMen: SFBUG:1724535 - correctly integrate a few more fixes from WiX v2 to
WiX v3.

JordanF: WixUnit now compares the transforms inside a patch when it is diffing
two patches. Previously, only the tables in the patch were compared.

AaronSte: Added documentation for properties and custom actions in the
WixVSExtension.

PMarcu: Fix for ServiceConfig CA's to call correct rollback entrypoint.

BMurri: Add support for bound wixouts/wixmsts to torch and pyro.

PMarcu: Fix for ServiceConfig CA's to call correct rollback entrypoint.

RobMen: Schema tweaks to enable simple references on FeatureRef and
FeatureGroupRef plus tweaks to enable floating Components.
AaronSte: Added documentation for Votive functionality.

AaronSte: Fixing variable resolution problem in WiX Product item template
in Votive.

PMarcu: Updating flags in XmlConfig to match with CA after the 2.0 to
3.0 integration.

JRock: Integrated the VS SDK 4.0 into Votive.

AaronSte: Merged WiX 2.0 documentation changes into 3.0. Updated instances
of deprecated src attributes in examples in the docs.

MikeHo: Add reinstall support & logging to Chainer + fix bug when using
transforms other than Chinese.

HeathS: SFBUG:1739868 - Pyro does not find .AllowRemoval property

PMarcu: Removing primary key from EnsureTable to support patching.
Fixing documentation for XmlConfig.

RobMen: SFBUG:1739194 - Preserve whitespace when using XmlFile or XmlConfig

JKuhne: Fix a GC related bug in the cab enumeration callback. (Cab.WixEnumerateCab.Enumerate)

--- NEW FILE: extension_development.htm ---

Developing WiX Extensions

Common Requirements
In order to understand how each of the classes of extensions work, one should start by looking at the WiX source code. All classes of extensions have the following things in common:

Implemented using the .NET Framework 1.1 or higher. The rest of the WiX toolset currently only depends on the .NET Framework 1.1, so in order to ensure backwards compatibility, it is a best practice to develop new extensions so that they only depend on the .NET Framework 1.1 as well.
Build a subclass of the appropriate extension object, which gives it an easily distinguishable name.
Build a schema of the appropriate syntax to provide validation checking where possible.
Build internal table definitions and register them with the compiler.
Build overrides for extensible methods and virtual members which will get invoked at the approriate location during the single pass compile.
Build extension into a DLL.
Place extension DLL next to WiX EXEs.
Registered with WiX via a command line argument to the compiler.

Considerations
Before investing in an extension, one should evaluate whether an external tool and the ?include syntax (from the preprocessor) will provide the needed flexibility for your technical needs.
Multiple extensions and extension types are supported, but there is no guarantee of the order in which a particular class of extensions will be processed. As a result, there must not be any sequencing dependencies between extensions within the same extension class.

Index: standard_customactions.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/standard_customactions.htm,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** standard_customactions.htm 18 Oct 2006 07:12:06 -0000 1.2
--- standard_customactions.htm 27 Jun 2007 05:36:14 -0000 1.3
***************
*** 2,41 ****

! Windows Installer XML Standard CustomActions

! Windows Installer XML Standard CustomActions

! The WiX toolset contains several CustomActions to handle configuring resources such as
Internet Information Services web sites and virtual directories, SQL Server databases
! and scripts, user accounts, file shares, and more. These CustomActions are provided in
! two separate .wixlibs: sca.wixlib and wixca.wixlib. The former contain "Server
! CustomActions" while the latter has more general installation CustomActions. In the future,
! these .wixlib's may merge together but for now (for mostly historical reasons) they are separate.

- sca.wixlib - Server CustomActions
-
- Internet Information Services (IIS) CustomAction - create and configure web sites, virtual directories, web applications, etc.
- SQL Server CustomAction - create databases and execute SQL scripts and statements.
- User CustomAction - create and configure new users.
- FileShare CustomAction - create and configure file shares (SMB).
- Performance Counter CustomAction - install and uninstall performance counters.
-
-
- wixca.wixlib - General CustomActions

! Secure Objects CustomAction - secure (using ACLs) objects that standard LockPermission table cannot. For further information see the Extended attribut in <Permission/>.
! Service Configuration CustomAction - configure attributes of a Windows Service that the ServiceInstall table cannot.
! Quiet Execution CustomAction - launch console executables without displaying a window.
! ShellExecute CustomAction - launch document or URL targets via the Windows shell.
! XmlFile CustomAction - allows you to configure XML files as part of your installation package. For further information see <XmlFile/>.

! New CustomActions are always under development. Our goal is to one day have standard CustomActions
! for just about any need. Feel free to open a Feature Request
! if you have a CustomAction need.

--- 2,38 ----

! Windows Installer XML Standard custom actions

! Windows Installer XML Standard custom actions

! The WiX toolset contains several custom actions to handle configuring resources such as
Internet Information Services web sites and virtual directories, SQL Server databases
! and scripts, user accounts, file shares, and more. These custom actions are provided in
! WiX extensions: WixIIsExtension, WixNetFxExtension, WixSqlExtension, WixUtilExtension,
! WixVSExtension.

! Internet Information Services (IIS) custom action (WixIIsExtension) - create and configure web sites, virtual directories, web applications, etc.
! SQL Server custom action (WixSqlExtension) - create databases and execute SQL scripts and statements.
! User custom action (WixUtilExtension) - create and configure new users.
! FileShare custom action (WixUtilExtension) - create and configure file shares (SMB).
! Performance Counter custom action (WixUtilExtension) - install and uninstall performance counters.
! Native Image custom action (WixNetFxExtension) - generate native code for .NET assemblies.
! Visual Studio custom actions (WixVSExtension) - detect Visual Studio editions and register VSPackages.
! Secure Objects custom action - secure (using ACLs) objects that standard LockPermission table cannot. For further information see the Extended attribute in <Permission/>.
! Service Configuration custom action - configure attributes of a Windows Service that the ServiceInstall table cannot.
! Quiet Execution custom action - launch console executables without displaying a window.
! ShellExecute custom action - launch document or URL targets via the Windows shell.
! OSInfo custom actions - set extra properties over the MSI set for OS information and standard directories.
! XmlFile custom action - allows you to configure XML files as part of your installation package. For further information see <XmlFile/>.

! New custom actions and extensions are always under development. Our goal is to one day have standard custom actions
! for just about any need. Feel free to open a Feature Request
! if you have a custom action or extension need.

Index: light.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/light.htm,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** light.htm 7 Nov 2005 22:47:30 -0000 1.1
--- light.htm 27 Jun 2007 05:36:14 -0000 1.2
***************
*** 24,27 ****
--- 24,31 ----
Finally, light works through the mechanics of generating IDT files and importing them into the Windows Installer database. After the database is fully created, the final post processing is done to merge in any Merge Modules and create a cabinet if necessary. The result is a fully functional Windows Installer database.

+ Additional Topics
+
+ Light usage information
+

\ No newline at end of file

--- NEW FILE: light_usage.htm ---

Light usage

Light usage

Light usage:

light.exe [-?] [-b basePath] [-nologo] [-out outputFile] objectFile [objectFile ...]

Light supports the following command line parameters:

Switch

Meaning

-ai

Allow identical rows; identical rows will be treated as a warning

-au

Allow unresolved references; this will cause invalid output to be created

-b

Specify a base path to locate all files; the default value is the current working directory

-bf

Bind files into a wixout; this switch is only valid when also providing the -xo option

-cc

Specify a path to cache built cabinet files; the path will not be deleted after linking

-ct <N>

Specify the number of threads to use when creating cabinets; the default is the %NUMBER_OF_PROCESSORS% environment variable

-cultures:<cultures>

Specify a semicolon-delimited list of localized string cultures to load from libraries

-cub

Provide a .cub file containing additional internal consistency evaluators (ICEs) to run

-d<name>=<value>

Define a WiX variable

-ext

Specify an extension assembly

-fv

Add a FileVersion attribute to each assembly in the MsiAssemblyName table (rarely needed)

-loc <loc.wxl>

Provide a .wxl file to read localization strings from

-nologo

Skip printing Light logo information

-notidy

Prevent Light from deleting temporary files after linking is complete (useful for debugging)

-out

Specify an output file; by default, Light will write to the current working directory

-pedantic

Display pedantic output messages

-reusecab

Reuse cabinets from the cabinet cache instead of rebuilding cabinets

-sa

Suppress assemblies: do not get assembly name information for assemblies

-sacl

Suppress resetting ACLs (useful when laying out an image to a network share)

-sadmin

Suppress adding default Admin sequence actions

-sadv

Suppress adding default Advt sequence actions

-sdut

Suppress dropping unreal tables to the output image; this switch is set by default when the -xo switch is provided

-sice:<ICE>

Suppress running internal consistency evaluators (ICEs) with specific IDs

-sma

Suppress processing the data in the MsiAssembly table

-sf

Suppress files: do not get any file information; this switch is equivalent to the combination of the -sa and -sh switches

-sh

Suppress file information: do not get hash, version, language and other file properties

-sl

Suppress layout creation

-ss

Suppress schema validation for documents; this switch provides a performance boost during linking

-sui

Suppress adding default UI sequence actions

-sv

Suppress intermediate file version mismatch checking

-sval

Suppress MSI/MSM validation

-sw<N>

Suppress warnings with specific message IDs

-ts

Tag sectionId attribute on rows; this switch is set by default when the -xo switch is provided

-tsa

Tag sectionId attribute on rows and generate the rows when null; this switch is set by default when the -xo switch is provided

-usf <output.xml>

Specify an unreferenced symbols file

-v

Generate verbose output

-wx

Treat warnings as errors

-xo

Generate XML output instead of an MSI

-?

Display Light help information

--- NEW FILE: votive_project_templates.htm ---

Votive Project Templates

Votive Project Templates
Introduction

Votive provides the following Visual Studio project templates:

WiX Project
WiX Library Project
WiX Merge Module Project

WiX Project

A WiX project provides a starting point that can be used to create a new Windows Installer package (.msi) file.

Each new WiX project includes a .wxs file that consists of a <Product> element that contains a skeleton with the WiX authoring required to create a fully functional Windows Installer package. The <Package> element includes <Package>, <Media>, <Directory>, <Component> and <Feature> elements.

WiX Library Project

A WiX library project provides a starting point that can be used to create a new WiX library (.wixlib) file. A .wixlib file is a library of setup functionality that can be easily shared across different WiX-based packages by including it when linking the setup package.

Each new WiX library project includes a .wxs file that consists of an empty <Fragment> element that can be populated with WiX authoring that can be shared by multiple packages.

WiX Merge Module Project

A WiX merge module project provides a starting point that can be used to create a new Windows Installer merge module (.msm) file. A merge module contains a set of Windows Installer resources that can be shared by multiple Windows Installer installation packages by merging the contents of the module into the .msi package.

Each new WiX merge module project includes a .wxs file that consists of a <Module> element that contains a skeleton with the WiX authoring required to create a fully functional merge module. The <Module> element includes <Package>, <Directory> and <Component> elements.

Creating WiX Projects

To create a new WiX project:

In Visual Studio, click on the File menu and select New | Project...
Click on WiX in the Project types tree control in the Add New Project dialog
Select the appropriate WiX project template, provide a name and location and click OK to create the new project

To add a new WiX project to an existing solution:

Right-click on the solution in the Visual Studio solution explorer, choose Add | New Project...
Click on WiX in the Project types tree control in the Add New Project dialog
Select the appropriate WiX project template, provide a name and location and click OK to create the new project and add it to the solution

Index: authoring_custom_actions.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/authoring_custom_actions.htm,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** authoring_custom_actions.htm 19 Jul 2006 05:54:26 -0000 1.3
--- authoring_custom_actions.htm 27 Jun 2007 05:36:13 -0000 1.4
***************
*** 24,28 ****
Return='check'/>

! <Binary Id='ScaSchedule' src='scasched.dll'/>
</Fragment>
</Wix>
--- 24,28 ----
Return='check'/>

! <Binary Id='ScaSchedule' SourceFile='scasched.dll'/>
</Fragment>
</Wix>
***************
*** 74,79 ****
DllEntry='ExecuteSqlStrings' Execute='rollback' Return='check'/>

! <Binary Id='ScaSchedule' src='scasched.dll'/>
! <Binary Id='ScaExecute' src='scaexec.dll'/>
</Fragment>
</Wix>
--- 74,79 ----
DllEntry='ExecuteSqlStrings' Execute='rollback' Return='check'/>

! <Binary Id='ScaSchedule' SourceFile='scasched.dll'/>
! <Binary Id='ScaExecute' SourceFile='scaexec.dll'/>
</Fragment>
</Wix>
***************
*** 100,107 ****
<Directory Id='MyDir' Name='Test Program'>
<Component Id='MyComponent' Guid='12345678-1234-1234-1234-123456789012'>
! <File Id='readme' Name='readme.txt' DiskId='1' src='readme.txt' />
</Component>

! <Merge Id='MyModule' Language='1033' src='module.msm' DiskId='1' />
</Directory>
</Directory>
--- 100,107 ----
<Directory Id='MyDir' Name='Test Program'>
<Component Id='MyComponent' Guid='12345678-1234-1234-1234-123456789012'>
! <File Id='readme' Name='readme.txt' DiskId='1' Source='readme.txt' />
</Component>

! <Merge Id='MyModule' Language='1033' SourceFile='module.msm' DiskId='1' />
</Directory>
</Directory>

--- NEW FILE: wixvsextension.htm ---

WixVSExtension

WixVSExtension

The WixVSExtension includes a set of custom actions to manage help collections. Detailed schema reference for the help collection custom actions can be found in the VS Schema documentation.

The WixVSExtension also includes a set of properties and custom actions that can be used to detect the presence of various versions of Visual Studio and register add-ins, project templates and item templates for use in Visual Studio. Here is a complete list:

WixVSExtension properties

VS2003DEVENV

Full path to devenv.exe for Visual Studio .NET 2003 if it is installed on the system.

JSHARP_REDIST_11_INSTALLED

Indicates whether or not the J# redistributable package 1.1 is installed on the system.

VS2005DEVENV

Full path to devenv.exe for Visual Studio 2005 if it is installed on the system.

VS2005_ITEMTEMPLATES_DIR

Full path to the Visual Studio 2005 item templates directory.

VS2005_PROJECTTEMPLATES_DIR

Full path to the Visual Studio 2005 project templates directory.

VS2005_SCHEMAS_DIR

Full path to the Visual Studio 2005 XML schemas directory.

VS2005PROJECTAGGREGATOR2

Indicates whether or not the Visual Studio 2005 project aggregator for managed code add-ins is installed on the system.

VS2005_ROOT_FOLDER

Full path to the Visual Studio 2005 root installation directory.

VB2005EXPRESS_IDE

Full path to vbexpress.exe if Visual Basic 2005 Express Edition is installed on the system.

VS2005_IDE_VB_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2005 Standard Edition or higher is installed and the Visual Basic project system is installed for it.

VC2005EXPRESS_IDE

Full path to vcexpress.exe if Visual C++ 2005 Express Edition is installed on the system.

VS2005_IDE_VC_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2005 Standard Edition or higher is installed and the Visual C++ project system is installed for it.

VCSHARP2005EXPRESS_IDE

Full path to vcsexpress.exe if Visual C# 2005 Express Edition is installed on the system.

VS2005_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2005 Standard Edition or higher is installed and the Visual C# project system is installed for it.

VJSHARP2005EXPRESS_IDE

Full path to vjsexpress.exe if Visual J# 2005 Express Edition is installed on the system.

VS2005_IDE_VJSHARP_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2005 Standard Edition or higher is installed and the Visual J# project system is installed for it.

VWD2005EXPRESS_IDE

Full path to vwdexpress.exe if Visual Web Developer 2005 Express Edition is installed on the system.

VS2005_IDE_VWD_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2005 Standard Edition or higher is installed and the Visual Web Developer project system is installed for it.

VS2005_IDE_VSTS_TESTSYSTEM_INSTALLED

Indicates whether or not the Visual Studio Team Test project system is installed on the system.

VSEXTENSIONS_FOR_NETFX30_INSTALLED

Indicates whether or not the Visual Studio 2008 Development Tools for the .NET Framework 3.0 add-in for Visual Studio 2005 is installed on the system.

VS2005_WAP_PROJECT_INSTALLED

Indicates whether or not the Web Application Project template for Visual Studio 2005 is installed on the system. This project template is available as a standalone add-in and as a part of visual Studio 2005 SP1.

VS2005_SP_LEVEL

Indicates the service pack level for Visual Studio 2005 Standard Edition and higher.

VSTF2005_SP_LEVEL

Indicates the service pack level for Visual Studio 2005 Team Foundation.

VB2005EXPRESS_SP_LEVEL

Indicates the service pack level for Visual Basic 2005 Express Edition.

VC2005EXPRESS_SP_LEVEL

Indicates the service pack level for Visual C++ 2005 Express Edition.

VCSHARP2005EXPRESS_SP_LEVEL

Indicates the service pack level for Visual C# 2005 Express Edition.

VJSHARP2005EXPRESS_SP_LEVEL

Indicates the service pack level for Visual J# 2005 Express Edition.

VWD2005EXPRESS_SP_LEVEL

Indicates the service pack level for Visual Web Developer 2005 Express Edition.

DEXPLORE_2005_INSTALLED

Indicates whether or not the Document Explorer 2005 runtime components package is installed on the system.

JSHARP_REDIST_20_INSTALLED

Indicates whether or not the J# redistributable package 2.0 is installed on the system.

VS90DEVENV

Full path to devenv.exe for Visual Studio 2008 if it is installed on the system.

VS90_ITEMTEMPLATES_DIR

Full path to the Visual Studio 2008 item templates directory.

VS90_PROJECTTEMPLATES_DIR

Full path to the Visual Studio 2008 project templates directory.

VS90_SCHEMAS_DIR

Full path to the Visual Studio 2008 XML schemas directory.

VS90_ROOT_FOLDER

Full path to the Visual Studio 2008 root installation directory.

VB90EXPRESS_IDE

Full path to vbexpress.exe if Visual Basic 2008 Express Edition is installed on the system.

VS90_IDE_VB_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2008 Standard Edition or higher is installed and the Visual Basic project system is installed for it.

VC90EXPRESS_IDE

Full path to vcexpress.exe if Visual C++ 2008 Express Edition is installed on the system.

VS90_IDE_VC_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2008 Standard Edition or higher is installed and the Visual C++ project system is installed for it.

VCSHARP90EXPRESS_IDE

Full path to vcsexpress.exe if Visual C# 2008 Express Edition is installed on the system.

VS90_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2008 Standard Edition or higher is installed and the Visual C# project system is installed for it.

VWD90EXPRESS_IDE

Full path to vwdexpress.exe if Visual Web Developer 2008 Express Edition is installed on the system.

VS90_IDE_VWD_PROJECTSYSTEM_INSTALLED

Indicates whether Visual Studio 2008 Standard Edition or higher is installed and the Visual Web Developer project system is installed for it.

VS90_IDE_VSTS_TESTSYSTEM_INSTALLED

Indicates whether or not the Visual Studio Team Test project system is installed on the system.

WixVSExtension custom actions

VS2003Setup

Runs devenv.exe /setup if a Visual Studio .NET 2003 edition is found on the system.

VS2005Setup

Runs devenv.exe /setup if Visual Studio 2005 Standard Edition or higher is found on the system. Including this custom action automatically adds the VS2005DEVENV property.

VS2005InstallVSTemplates

Runs devenv.exe /InstallVSTemplates if Visual Studio 2005 Standard Edition or higher is found on the system. Including this custom action automatically adds the VS2005DEVENV property.

VB2005Setup

Runs vbexpress.exe /setup if Visual Basic 2005 Express Edition is found on the system. Including this custom action automatically adds the VB2005EXPRESS_IDE property.

VB2005InstallVSTemplates

Runs vbexpress.exe /InstallVSTemplates if Visual Basic 2005 Express Edition is found on the system. Including this custom action automatically adds the VB2005EXPRESS_IDE property.

VC2005Setup

Runs vcexpress.exe /setup if Visual C++ 2005 Express Edition is found on the system. Including this custom action automatically adds the VC2005EXPRESS_IDE property.

VC2005InstallVSTemplates

Runs vcexpress.exe /InstallVSTemplates if Visual C++ 2005 Express Edition is found on the system. Including this custom action automatically adds the VC2005EXPRESS_IDE property.

VCSHARP2005Setup

Runs vcsexpress.exe /setup if Visual C# 2005 Express Edition is found on the system. Including this custom action automatically adds the VCSHARP2005EXPRESS_IDE property.

VCSHARP2005InstallVSTemplates

Runs vcsexpress.exe /InstallVSTemplates if Visual C# 2005 Express Edition is found on the system. Including this custom action automatically adds the VCSHARP2005EXPRESS_IDE property.

VJSHARP2005Setup

Runs vjsexpress.exe /setup if Visual J# 2005 Express Edition is found on the system. Including this custom action automatically adds the VJSHARP2005EXPRESS_IDE property.

VJSHARP2005InstallVSTemplates

Runs vjsexpress.exe /InstallVSTemplates if Visual J# 2005 Express Edition is found on the system. Including this custom action automatically adds the VJSHARP2005EXPRESS_IDE property.

VWD2005Setup

Runs vwdexpress.exe /setup if Visual Web Developer 2005 Express Edition is found on the system. Including this custom action automatically adds the VWD2005EXPRESS_IDE property.

VWD2005InstallVSTemplates

Runs vwdexpress.exe /InstallVSTemplates if Visual Web Developer 2005 Express Edition is found on the system. Including this custom action automatically adds the VWD2005EXPRESS_IDE property.

VS90Setup

Runs devenv.exe /setup if Visual Studio 2008 Standard Edition or higher is found on the system. Including this custom action automatically adds the VS90DEVENV property.

VS90InstallVSTemplates

Runs devenv.exe /InstallVSTemplates if Visual Studio 2008 Standard Edition or higher is found on the system. Including this custom action automatically adds the VS90DEVENV property.

VB90Setup

Runs vbexpress.exe /setup if Visual Basic 2008 Express Edition is found on the system. Including this custom action automatically adds the VB90EXPRESS_IDE property.

VB90InstallVSTemplates

Runs vbexpress.exe /InstallVSTemplates if Visual Basic 2008 Express Edition is found on the system. Including this custom action automatically adds the VB90EXPRESS_IDE property.

VC90Setup

Runs vcexpress.exe /setup if Visual C++ 2008 Express Edition is found on the system. Including this custom action automatically adds the VC90EXPRESS_IDE property.

VC90InstallVSTemplates

Runs vcexpress.exe /InstallVSTemplates if Visual C++ 2008 Express Edition is found on the system. Including this custom action automatically adds the VC90EXPRESS_IDE property.

VCSHARP90Setup

Runs vcsexpress.exe /setup if Visual C# 2008 Express Edition is found on the system. Including this custom action automatically adds the VCSHARP90EXPRESS_IDE property.

VCSHARP90InstallVSTemplates

Runs vcsexpress.exe /InstallVSTemplates if Visual C# 2008 Express Edition is found on the system. Including this custom action automatically adds the VCSHARP90EXPRESS_IDE property.

VWD90Setup

Runs vwdexpress.exe /setup if Visual Web Developer 2008 Express Edition is found on the system. Including this custom action automatically adds the VWD90EXPRESS_IDE property.

VWD90InstallVSTemplates

Runs vwdexpress.exe /InstallVSTemplates if Visual Web Developer 2008 Express Edition is found on the system. Including this custom action automatically adds the VWD90EXPRESS_IDE property.

To use the WixVSExtension properties or custom actions in an MSI, use the following steps:

Add PropertyRef or CustomActionRef elements for items listed above that you want to use in your MSI.
Add the -ext <path to WixVSExtension.dll> command line parameter when calling light.exe to include the WixVSExtension in the MSI linking process.

For example:

<PropertyRef Id="VS2005_ROOT_FOLDER" />
<CustomActionRef Id="VS2005Setup" />

When you reference any of the above properties or custom actions, the WixVSExtension automatically schedules the custom actions and pulls in properties used in the custom action conditions and execution logic.

--- NEW FILE: wxl.htm ---

Localization Files (.wxl)

Localization Files (.wxl)

A .wxl file contains a set of strings used for localizing a product into a specified culture. The root element of this file is <WixLocalization/>. The culture is specified by setting the Culture attribute on the <WixLocalization/> element.

Index: qtexec.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/qtexec.htm,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** qtexec.htm 7 Nov 2005 22:47:30 -0000 1.1
--- qtexec.htm 27 Jun 2007 05:36:14 -0000 1.2
***************
*** 16,20 ****
<Property Id="QtExecCmdLine" Value="command line to run"/>
<CustomAction Id="QtExec" BinaryKey="wixca" DllEntry="CAQuietExec" Execute="immediate" Return="check"/>
! <Binary Id="wixca" src="wixca.dll"/>
.
.
--- 16,20 ----
<Property Id="QtExecCmdLine" Value="command line to run"/>
<CustomAction Id="QtExec" BinaryKey="wixca" DllEntry="CAQuietExec" Execute="immediate" Return="check"/>
! <Binary Id="wixca" SourceFile="wixca.dll"/>
.
.
***************
*** 52,56 ****
<Property Id="QtExecDeferred" Value="command line to run"/>
<CustomAction Id="QtExecDeferred" BinaryKey="wixca" DllEntry="CAQuietExec" Execute="deferred" Return="check"/>
! <Binary Id="wixca" src="wixca.dll"/>
.
.
--- 52,56 ----
<Property Id="QtExecDeferred" Value="command line to run"/>
<CustomAction Id="QtExecDeferred" BinaryKey="wixca" DllEntry="CAQuietExec" Execute="deferred" Return="check"/>
! <Binary Id="wixca" Sourcefile="wixca.dll"/>
.
.

Index: WixUI_dialog_library.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/WixUI_dialog_library.htm,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** WixUI_dialog_library.htm 13 Dec 2006 07:44:20 -0000 1.4
--- WixUI_dialog_library.htm 27 Jun 2007 05:36:13 -0000 1.5
***************
*** 36,44 ****
installed.Note: To use WixUI_InstallDir, you must set a property
named WIXUI_INSTALLDIR with a value of the ID of the directory you want the
! user to be able to specify the location of. For example:

<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder" Name="PFiles">
! <Directory Id="TESTFILEPRODUCTDIR" ShortName="WIXTEST" Name="Test File">
...
</Directory>
--- 36,46 ----
installed.Note: To use WixUI_InstallDir, you must set a property
named WIXUI_INSTALLDIR with a value of the ID of the directory you want the
! user to be able to specify the location of. Note that the directory ID must
! be all uppercase characters, as it must be passed from the UI to the
! execute sequence to take effect. For example:

<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder" Name="PFiles">
! <Directory Id="TESTFILEPRODUCTDIR" Name="Test File">
...
</Directory>

Index: extensions.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/extensions.htm,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** extensions.htm 7 Nov 2005 22:47:30 -0000 1.1
--- extensions.htm 27 Jun 2007 05:36:13 -0000 1.2
***************
*** 7,35 ****

Extensions
! WiX has support for three classes of extensions

- Introduction

Preprocessor Extensions allow clients to modify authoring files before they are processed by the compiler.
! Compiler Extensions allow clients to custom compile authored XML into internal table representation before it's written to binary form.
Binder Extensions allow clients to the feed the interlace image processing and data finalization.

- Through these extensions one can extend WiX to support custom preprocessing, XML syntax compilation, or binding semantics for ones particular layout generation process.

! Common Requirements
! How to use each should start in the source code but they all have a few things in common

! Implemented in same version of .NET 1.1 as the rest of WiX
! Build a subclass of the appropriate extension object giving it a easily distinguishable name.
! Build a schema of the appropriate syntax to provide validation checking where possible.
! Build internal table definitions and register them with the compiler.
! Build overrides for extendable methods and virtual members which will get invoked at the approriate location during the single pass compile.
! Build extension into a DLL.
! Place extension DLL next to WiX EXEs.
! Registered with WiX via command line argument to the compiler

! Considerations
! Before investing in an extension, one should evaluate whether an external tool and the ?include syntax (from the preprocessor) will provide the needed flexability for your technical needs.
! Multiple extensions and extension types are supported but there is no guarentee of the order a particular class of extensions will be processes so there should be no sequencing dependencies between extensions within the same extension class.

\ No newline at end of file
--- 7,27 ----

Extensions
! WiX supports three classes of extensions:

Preprocessor Extensions allow clients to modify authoring files before they are processed by the compiler.
! Compiler Extensions allow clients to custom compile authored XML into internal table representation before it is written to binary form.
Binder Extensions allow clients to the feed the interlace image processing and data finalization.

! Through these extensions, one can extend WiX to support custom pre-processing, XML syntax compilation, or binding semantics for a particular layout generation process.
!
! The following topics contain documentation about using existing WiX extensions and developing new WiX extensions:
!

! Developing WiX extensions
! Visual Studio extension (WixVSExtension)

!

\ No newline at end of file

--- NEW FILE: osinfo.htm ---

OSInfo custom actions

OSInfo custom actions

The WixQueryOsInfo and WixQueryOsDirs custom actions in wixca (part of WixUtilExtension) set properties over and above the MSI set for OS
product/suite detection and standard directories. Here is a complete list:

WixQueryOsInfo properties

WIX_SUITE_BACKOFFICE

Equivalent to the OSVERSIONINFOEX VER_SUITE_BACKOFFICE flag.

WIX_SUITE_BLADE

Equivalent to the OSVERSIONINFOEX VER_SUITE_BLADE flag.

WIX_SUITE_COMMUNICATIONS

Equivalent to the OSVERSIONINFOEX VER_SUITE_COMMUNICATIONS flag.

WIX_SUITE_COMPUTE_SERVER

Equivalent to the OSVERSIONINFOEX VER_SUITE_COMPUTE_SERVER flag.

WIX_SUITE_DATACENTER

Equivalent to the OSVERSIONINFOEX VER_SUITE_DATACENTER flag.

WIX_SUITE_EMBEDDEDNT

Equivalent to the OSVERSIONINFOEX VER_SUITE_EMBEDDEDNT flag.

WIX_SUITE_EMBEDDED_RESTRICTED

Equivalent to the OSVERSIONINFOEX VER_SUITE_EMBEDDED_RESTRICTED flag.

WIX_SUITE_ENTERPRISE

Equivalent to the OSVERSIONINFOEX VER_SUITE_ENTERPRISE flag.

WIX_SUITE_MEDIACENTER

Equivalent to the GetSystemMetrics SM_SERVERR2 flag.

WIX_SUITE_PERSONAL

Equivalent to the OSVERSIONINFOEX VER_SUITE_PERSONAL flag.

WIX_SUITE_SECURITY_APPLIANCE

Equivalent to the OSVERSIONINFOEX VER_SUITE_SECURITY_APPLIANCE flag.

WIX_SUITE_SERVERR2

Equivalent to the GetSystemMetrics SM_SERVERR2 flag.

WIX_SUITE_SINGLEUSERTS

Equivalent to the OSVERSIONINFOEX VER_SUITE_SINGLEUSERTS flag.

WIX_SUITE_SMALLBUSINESS

Equivalent to the OSVERSIONINFOEX VER_SUITE_SMALLBUSINESS flag.

WIX_SUITE_SMALLBUSINESS_RESTRICTED

Equivalent to the OSVERSIONINFOEX VER_SUITE_SMALLBUSINESS_RESTRICTED
flag.

WIX_SUITE_STARTER

Equivalent to the GetSystemMetrics SM_STARTER flag.

WIX_SUITE_STORAGE_SERVER

Equivalent to the OSVERSIONINFOEX VER_SUITE_STORAGE_SERVER flag.

WIX_SUITE_TABLETPC

Equivalent to the GetSystemMetrics SM_TABLETPC flag.

WIX_SUITE_TERMINAL

Equivalent to the OSVERSIONINFOEX VER_SUITE_TERMINAL flag.

WIX_SUITE_WH_SERVER

Windows Home Server. Equivalent to the OSVERSIONINFOEX
VER_SUITE_WH_SERVER flag.

WixQueryOsDirs properties

WIX_DIR_ADMINTOOLS

Per-user administrative tools directory. Equivalent to the
SHGetFolderPath CSIDL_ADMINTOOLS flag.

WIX_DIR_ALTSTARTUP

Per-user nonlocalized Startup program group. Equivalent to the
SHGetFolderPath CSIDL_ALTSTARTUP flag.

WIX_DIR_CDBURN_AREA

Per-user CD burning staging directory. Equivalent to the
SHGetFolderPath CSIDL_CDBURN_AREA flag.

WIX_DIR_COMMON_ADMINTOOLS

All-users administrative tools directory. Equivalent to the
SHGetFolderPath CSIDL_COMMON_ADMINTOOLS flag.

WIX_DIR_COMMON_ALTSTARTUP

All-users nonlocalized Startup program group. Equivalent to the
SHGetFolderPath CSIDL_COMMON_ALTSTARTUP flag.

WIX_DIR_COMMON_DOCUMENTS

All-users documents directory. Equivalent to the SHGetFolderPath
CSIDL_COMMON_DOCUMENTS flag.

WIX_DIR_COMMON_FAVORITES

All-users favorite items directory. Equivalent to the
SHGetFolderPath CSIDL_COMMON_FAVORITES flag.

WIX_DIR_COMMON_MUSIC

All-users music files directory. Equivalent to the
SHGetFolderPath CSIDL_COMMON_MUSIC flag.

WIX_DIR_COMMON_PICTURES

All-users picture files directory. Equivalent to the
SHGetFolderPath CSIDL_COMMON_PICTURES flag.

WIX_DIR_COMMON_VIDEO

All-users video files directory. Equivalent to the
SHGetFolderPath CSIDL_COMMON_VIDEO flag.

WIX_DIR_COOKIES

Per-user Internet Explorer cookies directory. Equivalent to the
SHGetFolderPath CSIDL_COOKIES flag.

WIX_DIR_DESKTOP

Per-user desktop directory. Equivalent to the SHGetFolderPath
CSIDL_DESKTOP flag.

WIX_DIR_HISTORY

Per-user Internet Explorer history directory. Equivalent to the
SHGetFolderPath CSIDL_HISTORY flag.

WIX_DIR_INTERNET_CACHE

Per-user Internet Explorer cache directory. Equivalent to the
SHGetFolderPath CSIDL_INTERNET_CACHE flag.

WIX_DIR_MYMUSIC

Per-user music files directory. Equivalent to the
SHGetFolderPath CSIDL_MYMUSIC flag.

WIX_DIR_MYPICTURES

Per-user picture files directory. Equivalent to the
SHGetFolderPath CSIDL_MYPICTURES flag.

WIX_DIR_MYVIDEO

Per-user video files directory. Equivalent to the
SHGetFolderPath CSIDL_MYVIDEO flag.

WIX_DIR_NETHOOD

Per-user My Network Places link object directory. Equivalent to the
SHGetFolderPath CSIDL_NETHOOD flag.

WIX_DIR_PERSONAL

Per-user documents directory. Equivalent to the SHGetFolderPath
CSIDL_PERSONAL flag.

WIX_DIR_PRINTHOOD

Per-user Printers link object directory. Equivalent to the
SHGetFolderPath CSIDL_PRINTHOOD flag.

WIX_DIR_PROFILE

Per-user profile directory. Equivalent to the SHGetFolderPath
CSIDL_PROFILE flag.

WIX_DIR_RECENT

Per-user most recently used documents shortcut directory. Equivalent
to the SHGetFolderPath CSIDL_RECENT flag.

WIX_DIR_RESOURCES

All-users resource data directory. Equivalent to the
SHGetFolderPath CSIDL_RESOURCES flag.

To use the WixQueryOsInfo and WixQueryOsDirs custom actions, add PropertyRef elements for the properties above you want to be set and
add WixUtilExtension to your link options (a.k.a. the Light command line). For example:

<PropertyRef Id="WIX_SUITE_SINGLEUSERTS" />
<PropertyRef Id="WIX_DIR_COMMON_DOCUMENTS" />

WixUtilExtension automatically schedules the custom actions as needed after the AppSearch standard action.

For additonal information about standard directory tokens in Windows and which ones are supported directly
by Windows Installer, see the following topics in the MSDN documentation:

Constant special item ID list (CSIDL) values
Windows Installer system folder values

Index: robmen_20040405.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/robmen_20040405.htm,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** robmen_20040405.htm 19 Jul 2006 05:54:26 -0000 1.3
--- robmen_20040405.htm 27 Jun 2007 05:36:14 -0000 1.4
***************
*** 19,23 ****
<Directory Id='TestAssemblyProductDirectory' Name='Test Assembly'>
<Component Id='TestAssemblyProductComponent' Guid='00030829-0000-0000-C000-000000000046'>
! <File Id='TestAssemblyProductFile' Name='assembly.dll' essembly='.net' KeyPath='yes' DiskId='1' src='$(env.WIX)\examples\data\assembly.dll'/>
</Component>
</Directory>
--- 19,23 ----
<Directory Id='TestAssemblyProductDirectory' Name='Test Assembly'>
<Component Id='TestAssemblyProductComponent' Guid='00030829-0000-0000-C000-000000000046'>
! <File Id='TestAssemblyProductFile' Name='assembly.dll' Assembly='.net' KeyPath='yes' DiskId='1' Source='$(env.WIX)\examples\data\assembly.dll'/>
</Component>
</Directory>

Index: robmen_20040511.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/robmen_20040511.htm,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** robmen_20040511.htm 19 Jul 2006 05:54:26 -0000 1.3
--- robmen_20040511.htm 27 Jun 2007 05:36:14 -0000 1.4
***************
*** 35,39 ****
      <DirectoryRef Id='MyDirectory'>
         <Component Id='MyComponent' Guid='00000000-0000-0000-0000-00000000000' DiskId='1'>
!             <File Id='MyFile' Name='My File.txt' src='present.txt'/>
         </Component>
      </DirectoryRef>
--- 35,39 ----
      <DirectoryRef Id='MyDirectory'>
         <Component Id='MyComponent' Guid='00000000-0000-0000-0000-00000000000' DiskId='1'>
!             <File Id='MyFile' Name='My File.txt' Source='present.txt'/>
         </Component>
      </DirectoryRef>
***************
*** 59,63 ****
"But how did it work?"
Well, when candle compiles your source code it creates an object file (.wixobj) that has zero or more sections in it. The elements that are children of the <Wix/> element (namely: <Product/>, <Module/>, and <Fragment/>) define a new section. So in the example above, product.wxs defines one section and fragment.wxs defines another.
! Sections contain data and references. Most of the data in the section is information that will end up in the final package (MSI file). Some of the data is just information needed by the linker or binder to build the package. For example, the <File/> element shown above contains the necessary information to define a file Resource in the package as well as the "src" attribute that tells the binder where to find the physical file on disk so that the file can be put into a cabinet and inserted into the package. Finally, the data in the section is used to define all of the symbols for the section.
A symbol is the unique identifier for a WiX element in your .wxs source file. In general, the symbol for an element maps to the primary key columns of the MSI table the WiX element represents. For example, the <File/> element's "Id" attribute in WiX maps to the MSI File table's File column which is the primary key column. It is pretty safe to assume that all "Id" attributes in the WiX schema represent symbols. If I was to take a stab at the symbols defined in the example source files above, I think this would be the list:product.wxs
Product:00000000-0000-0000-0000-000000000000
--- 59,63 ----
"But how did it work?"
Well, when candle compiles your source code it creates an object file (.wixobj) that has zero or more sections in it. The elements that are children of the <Wix/> element (namely: <Product/>, <Module/>, and <Fragment/>) define a new section. So in the example above, product.wxs defines one section and fragment.wxs defines another.
! Sections contain data and references. Most of the data in the section is information that will end up in the final package (MSI file). Some of the data is just information needed by the linker or binder to build the package. For example, the <File/> element shown above contains the necessary information to define a file Resource in the package as well as the "Source" attribute that tells the binder where to find the physical file on disk so that the file can be put into a cabinet and inserted into the package. Finally, the data in the section is used to define all of the symbols for the section.
A symbol is the unique identifier for a WiX element in your .wxs source file. In general, the symbol for an element maps to the primary key columns of the MSI table the WiX element represents. For example, the <File/> element's "Id" attribute in WiX maps to the MSI File table's File column which is the primary key column. It is pretty safe to assume that all "Id" attributes in the WiX schema represent symbols. If I was to take a stab at the symbols defined in the example source files above, I think this would be the list:product.wxs
Product:00000000-0000-0000-0000-000000000000

--- NEW FILE: votive_property_pages.htm ---

Votive Project Property Pages

Votive Project Property Pages
Introduction

To access Votive property pages, right-click on a WiX project in the Visual Studio Solution Explorer and choose Properties.

WiX projects contain the following property pages:

General
Build Events
Compiler
Linker (for WiX projects and WiX merge module projects)
Librarian (for WiX library projects)

General Property Page

The General tab contains the following configurable options:

Output name - a text box that contains the name of the resultant .msi, .msm or .wixlib file that will be created by the build process.
Output type - a radio button group that allows you to select the output type (a .msi, .msm or .wixlib file).

Build Events Property Page

The Build Events tab contains the following configurable options:

Pre-build event command line - a text box that contains the pre-build events to execute before building the current project.
Post-build event command line - a text box that contains the post-build events to execute after building the current project.
Run the post-build event - a drop-down combo box that allows you to specify the conditions in which post-build events should be executed.

The Build Events tab contains buttons named Edit Pre-build... and Edit Post-build... that display edit dialogs for the pre and post-build event command lines. The edit dialogs contain a list of all valid WiX project reference variables and their values based on the current project settings.

Compiler Property Page

The Compiler tab allows you to configure settings used by Candle (the WiX compiler). This tab contains the following groups of settings:

The General section allows you to define configuration-specific constants and specify the output path for the compilation process.
The Errors and Warnings section allows you toggle treating warnings as errors and showing pedantic compilation messages.
The Suppress Warnings section allows you to disable warnings for specified warning types.

In addition, the Compiler tab contains an Advanced... button that displays a Candle Advanced Settings dialog. This dialog allows you to configure the following settings:

Toggle suppressing schema validation of documents.
Toggle showing source traces for errors, warnings and verbose messages.
Toggle showing verbose compilation output.
Add include paths that will be used during compilation.

Linker Property Page

WiX projects and WiX merge module projects include a Linker tab in the property pages. The Linker tab allows you to configure settings used by Light (the WiX linker). This tab contains the following groups of settings:

The General section allows you to define configuration-specific constants, specify the output path for the linking process and specify cultures to include during the linking process.
The Errors and Warnings section allows you toggle treating warnings as errors and showing pedantic linking messages.
The Suppress Warnings section allows you to disable warnings for specified warning types.

In addition, the Linker tab contains an Advanced... button that displays a Light Advanced Settings dialog. This dialog contains the following tabs:

Advanced – this tab allows you to toggle verbose linker output, treating identical rows as warnings instead of errors, adding a fileVersion attribute to assemblies in the MsiAssemblyName table and deleting temporary files used during linking.
Cabinet – this tab allows you to specify the number of threads to use when creating cabinets, toggle whether to reuse cabinets from the cabinet cache and specify the location of the cabinet cache to reuse cabinets from.
Suppressions – this tab allows you to toggle all of the suppression types that are supported by the linker. For more details about supported suppression types, see the Light usage information.

Librarian Property Page

WiX library projects include a Librarian tab in the property pages. The Librarian tab allows you to configure settings used by Lit (the WiX library tool). This tab contains the following groups of settings:

The General section allows you to specify the output path for the library file and toggle whether or not to bind files into the library file.
The Errors and Warnings section allows you toggle treating warnings as errors, suppressing schema validation for documents, suppressing intermediate file version mismatch checking and displaying verbose output
The Suppress Warnings section allows you to disable warnings for specified warning types.

Index: robmen_20041130.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/robmen_20041130.htm,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** robmen_20041130.htm 16 Aug 2006 05:18:16 -0000 1.5
--- robmen_20041130.htm 27 Jun 2007 05:36:14 -0000 1.6
***************
*** 7,11 ****
Creating localized MSI files using WiX toolset and .wxl files.

! Tonight we pick up where I left off last week and continue with the topic of localizing your MSI file. If you haven't read last week's blog entry, you should do that now. Yes, it's pretty long. Don't worry I'll wait. There's lots of good background information in there. Great, I want to cover a couple more things before we really get started. First, just like in my previous blog entry all of the information presented here works equally well for Merge Modules (MSM files) as it does for MSI files. I'll be using an MSI file in my example and I'll use the words "MSI file" a lot (that's how I get such a high page rank for Windows Installer stuff... just kidding) because I'm lazy and get tired of writing MSI/MSM file. Second, I am using the latest build of the WiX toolset v2.0.2328.0 in my examples. This is important because, as you'll note in the release notes, I fixed many localization issues with this release of the toolset. If you want to follow along, be sure you have a recent version of the WiX toolset. Today there are really two ways to localize your MSI file. Step 3 and step 4 of the Localization Example in the Windows Installer SDK that I pointed at last week demonstrate those two methods
. First, you can export your MSI file's tables to IDT file format, localize that text file then import the IDT file back into your MSI. This method is the fastest way to update information in your MSI file. However, it also requires the most care because you must ensure the codepage of the IDT file matches the codepage of the MSI file or the import will fail with terribly helpful error messages like, "Failed to import your IDT file for some reason. Have a nice day" (note: ::MsiGetLastErrorRecord() will give you more information about the error but it rarely gives you the exact answer to the issue). It is interesting to note that the remarks in ::MsiDatabaseImport() function discourage using this method for updating your MSI file because of the code
page and other IDT encoding issues (like tabs and carriage returns). The second way to localize data in your MSI file is to use the Windows Installer SQL Syntax to update the appropriate columns. This method is arguably easier than the previous method because you don't have to worry about encoding tabs or carriage returns and the APIs will attempt to encode your text the best it can to match the MSI file's current codepage. Unfortunately, this method is also slower than the previous method because the Windows Installer SQL processor is not particularly speedy. So how about a solution that provides you, the setup developer, with the fastest method to create localized MSI files without needing to worry too much about encoding all of your data in IDT files correctly? What if all you needed to do was to provide the localized data and the codepage for that data (codepage
is still necessary because I don't know how to look at several random strings of text and accurately reverse engineer the codepage from them)? What if you could actually compile all of your source code files once then only link the object files together once for each language? How? Well with the WiX toolset, of course. Admittedly, the WiX toolset's localization features are some of the least documented features in the WiX toolset. In fact, the only documentation is WiX Localization file, .wxl files, schema (wixloc.xsd) and the code in light.cs that processes the .wxl files. So I'm here now to turn that all around with a step-by-step example. Let's look at a small example source file that installs a simple file with a shortcut. Let's call this source file "example.wxs": <?xml version='1.0'?> <Wix xmlns='http:/ / schemas.microsoft.com/wix/2006/wi'> &nb
sp; <Product Id='*' Name='ExampleProduct' Language='1033' Version='1.0.0.0' Manufacturer='Microsoft Corporation'> <Package Description='Example Description for Product' Comments='Example Product to demonstrate localized Data' InstallerVersion='200' Compressed='yes' /> <Media Id='1' Cabinet='product.cab' EmbedCab='yes' /> <Directory Id='TARGETDIR' Name='SourceDir'> <Directory Id='ProgramFilesFolder' Name='PFiles'> <Directory Id='EXAMPLEDIR' Name='Example Directory'> <Directory Id='LangDir' Name='1033'> &nbs
p; <Component Id='ExampleComponent' Guid='PUT-GUID-HERE' DiskId='1'> <File Id='ExampleFile' Name='example.txt' src='example.txt'> <Shortcut Id='ExampleShortcut' Directory='ProgramMenuFolder' Name='Example Shortcut' Description='Shortcut to example.txt'/> </File>
</Component> </Directory> </Directory> </Directory> <Directory Id='ProgramMenuFolder' Name='ProgMenu'/> </Directory> <Feature Id='ExampleFeature' Title='Example Feature for Product' Level='1'> <ComponentRef Id='ExampleComponent' /> </Feature> </Product> </Wix> Note, to compile the code above with candle.exe, you'll need to replace "PUT-GUID-HERE" with your own GUID. I don't provide GUIDs in my examples because people like to copy the examples then forget to change the GUID before shipping. Of course, that would be an immediate Component Rule violation and I don't want to be responsible for that. Also, before we can link that code with light.exe, we'll need to create a text file called, "example.txt". Here's what my example.txt file looks like: Each day is a gift, that's why we call it the present. Okay, after creating example.wxs (and adding your own GUID) and creating example.txt, you should be able to create an "example.msi" file by compiling and linking the files like so: C:\wix>candle example.wxs Microsoft (R) Windows Installer Xml Compiler version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. example.wxs C:\wix>light example.wixobj Microsoft (R) Windows Installer Xml Linker version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\wix> As always, no news from
light.exe is good news. You can install the newly created MSI file using "msiexec /i example.msi" and should notice a new shortcut in your ProgramMenuFolder ("Start" -> "All Programs" on Windows XP). But I'm sure for you old WiX toolset hacks out there this example is boring. So, let's get to localizing. If you used the preprocessor, you are already familiar with $(var.VAR) for defined variables and $(env.VAR) for environment variables. Localization in the WiX toolset is done by inserting "localization variables". Localization variables look like !(loc.VAR). Let's look at our modified source file: <?xml version='1.0'?> <Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'> <Product Id='*' Name='ExampleProduct' Language='!(loc.LANG)' Version='1.0.0.0' Manufacturer='Microsoft Corporation'> <Package Description='!(loc.Description)' Comments='!(loc.Comments)' InstallerVersion='200' Compressed='yes' /> <Media Id='1' Cabinet='product.cab' EmbedCab='yes' /> <Directory Id='TARGETDIR' Name='SourceDir'> <Directory Id='ProgramFilesFolder' Name='PFiles'> <Directory Id='EXAMPLEDIR' ShortName='!(loc.ShortDirName)' Name='!(loc.LongDirName)'> <Directory Id='LangDir' Name='!(loc.LANG)'> <Component Id='ExampleComponent' Guid='PUT-GUID-HERE' DiskId='1'> <Fi
le Id='ExampleFile' Name='!(loc.FileName)' src='example.txt'> <Shortcut Id='ExampleShortcut' Directory='ProgramMenuFolder' Name='!(loc.ShortShortcutName)' Description='!(loc.LongShortcutName)'/> </File> </Component> </Directory> </Directory>
</Directory> <Directory Id='ProgramMenuFolder' Name='ProgMenu'/> </Directory> <Feature Id='ExampleFeature' Title='!(loc.FeatureTitle)' Level='1'> <ComponentRef Id='ExampleComponent' /> </Feature> </Product> </Wix> You should again be able to compile that file but if you try to link you should see error messages such as, "light.exe : fatal error LGHT0023: Localization string 'FeatureTitle' unknown. Ensure that the !(loc.FeatureTitle) is defined." That error message basically means we did not provide a Localization file with all of the localizable identifiers and text. So, now we need to create our first .wxl file. I've called mine example1033.wxl and it goes a little like this: <?x
ml version='1.0'?> <WixLocalization xmlns='http://schemas.microsoft.com/wix/2006/localization' Codepage='1252'> <String Id='LANG'>1033</String> <String Id='Description'>Example Description for Product</String> <String Id='Comments'>Example Product to demonstrate localized Data</String> <String Id='ShortDirName'>example</String> <String Id='LongDirName'>Example Directory</String> <String Id='Filename'>example.txt</String> <String Id='ShortShortcutName'>Example</String> <String Id='LongShortcutName'>Shortcut to example.txt</String> <String Id='FeatureTitle'>Example Feature for Product</String> </WixLocalization> Now, to get our MSI file back. C:\wix>candle example.wxs Microsoft (R) W
indows Installer Xml Compiler version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. example.wxs C:\wix>light example.wixobj -loc example1033.wxl Microsoft (R) Windows Installer Xml Linker version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\wix> I want to note that (barring any typos) this MSI file should be identical to the first MSI file we created. I also want to note that this will be the last time we compile the example.wxs. Since we have specified all of our localization variables we no longer need to compile to get changes in our MSI file. All we need to do localize our example1033.wxl file into other languages. Since, I don't know any other languages, I'm going to localize our example1033.wxl file into the "Foo language" and use the Japanese LCID, 1041, since I happen to remember that one. Here's the
example1041.wxl file localized into the "Foo language": <?xml version='1.0'?> <WixLocalization xmlns='http://schemas.microsoft.com/wix/2006/localization' Codepage='932'> <String Id='LANGID'>1041</String> <String Id='Description'>Foo Foo foo Foo</String> <String Id='Comments'>Foo Foo foo foo foo Foo</String> <String Id='ShortDirName'>Foo</String> <String Id='LongDirName'>Foo Foo</String> <String Id='Filename'>foo.txt</String> <String Id='ShortShortcutName'>Foo</String> <String Id='LongShortcutName'>Foo foo foo.txt</String> <String Id='FeatureTitle'>Foo Foo foo Foo</String> </WixLocalization> Notice how elegant the "Foo language" is. The elegance really is lost in text format. So much of t
he "Foo language" is transmitted via the pitch and duration of each word. But I digress. Let's build our "Foo language" example.msi file. This will just stomp over our previous example.msi so make sure you uninstall the previous example.msi file using "msiexec /x example.msi" (or you'll have to go to Control Panel -> Add/Remove Programs). Let's link (and only link) our MSI file: C:\wix>light example.wixobj -loc example1041.wxl Microsoft (R) Windows Installer Xml Linker version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\wix> Now if you install the MSI file you are likely to see square boxes for the ActionText during the progress dialog box. I believe this occurs when you don't have the Japanese fonts necessary to display the Windows Installer's default text messages. In any case, I don't have Japanese fonts installed on my machine so I see square b
oxes. However, square boxes or no square boxes everything should install just fine. After installing, you too should see a "Foo" shortcut in your ProgramMenuFolder. That's all there is to .wxl files. Hopefully, you can see how the Localization files can greatly simplify the relationship between you, your localizers, and your setup. I would also like to note that .wxl files are relatively new constructs in the WiX toolset so if you have suggestions how to improve them please feel free to send your feedback to the "wix-devs at sourceforge.net" mailing list. And that brings me to my final point. There is one very fatal flaw in the code above. I debated delaying this blog entry to fix the issue but decided the content here was valuable even with the mistake. Have you found it yet? Look closely at the Component/@Guid attribute. Did that value change each time you created a completely different Component like the
step 9 in the Localization Overview suggests? Probably not because you can't currently localize GUID values as described by this bug on SourceForge. However, the value should change because you have very different Shortcuts in the two Components (and the example.txt file is installed to different locations so there is no overlap). So, I apologize profusely for creating an example that violates the Component Rules and I will fix the bug ASAP. In the meantime, have fun playing with your .wxl files and keep coding.
Copyright © Rob Mensching

--- 7,11 ----
Creating localized MSI files using WiX toolset and .wxl files.

! Tonight we pick up where I left off last week and continue with the topic of localizing your MSI file. If you haven't read last week's blog entry, you should do that now. Yes, it's pretty long. Don't worry I'll wait. There's lots of good background information in there. Great, I want to cover a couple more things before we really get started. First, just like in my previous blog entry all of the information presented here works equally well for Merge Modules (MSM files) as it does for MSI files. I'll be using an MSI file in my example and I'll use the words "MSI file" a lot (that's how I get such a high page rank for Windows Installer stuff... just kidding) because I'm lazy and get tired of writing MSI/MSM file. Second, I am using the latest build of the WiX toolset v2.0.2328.0 in my examples. This is important because, as you'll note in the release notes, I fixed many localization issues with this release of the toolset. If you want to follow along, be sure you have a recent version of the WiX toolset. Today there are really two ways to localize your MSI file. Step 3 and step 4 of the Localization Example in the Windows Installer SDK that I pointed at last week demonstrate those two methods
. First, you can export your MSI file's tables to IDT file format, localize that text file then import the IDT file back into your MSI. This method is the fastest way to update information in your MSI file. However, it also requires the most care because you must ensure the codepage of the IDT file matches the codepage of the MSI file or the import will fail with terribly helpful error messages like, "Failed to import your IDT file for some reason. Have a nice day" (note: ::MsiGetLastErrorRecord() will give you more information about the error but it rarely gives you the exact answer to the issue). It is interesting to note that the remarks in ::MsiDatabaseImport() function discourage using this method for updating your MSI file because of the code
page and other IDT encoding issues (like tabs and carriage returns). The second way to localize data in your MSI file is to use the Windows Installer SQL Syntax to update the appropriate columns. This method is arguably easier than the previous method because you don't have to worry about encoding tabs or carriage returns and the APIs will attempt to encode your text the best it can to match the MSI file's current codepage. Unfortunately, this method is also slower than the previous method because the Windows Installer SQL processor is not particularly speedy. So how about a solution that provides you, the setup developer, with the fastest method to create localized MSI files without needing to worry too much about encoding all of your data in IDT files correctly? What if all you needed to do was to provide the localized data and the codepage for that data (codepage
is still necessary because I don't know how to look at several random strings of text and accurately reverse engineer the codepage from them)? What if you could actually compile all of your source code files once then only link the object files together once for each language? How? Well with the WiX toolset, of course. Admittedly, the WiX toolset's localization features are some of the least documented features in the WiX toolset. In fact, the only documentation is WiX Localization file, .wxl files, schema (wixloc.xsd) and the code in light.cs that processes the .wxl files. So I'm here now to turn that all around with a step-by-step example. Let's look at a small example source file that installs a simple file with a shortcut. Let's call this source file "example.wxs": <?xml version='1.0'?> <Wix xmlns='http:/ / schemas.microsoft.com/wix/2006/wi'> &nb
sp; <Product Id='*' Name='ExampleProduct' Language='1033' Version='1.0.0.0' Manufacturer='Microsoft Corporation'> <Package Description='Example Description for Product' Comments='Example Product to demonstrate localized Data' InstallerVersion='200' Compressed='yes' /> <Media Id='1' Cabinet='product.cab' EmbedCab='yes' /> <Directory Id='TARGETDIR' Name='SourceDir'> <Directory Id='ProgramFilesFolder' Name='PFiles'> <Directory Id='EXAMPLEDIR' Name='Example Directory'> <Directory Id='LangDir' Name='1033'> &nbs
p; <Component Id='ExampleComponent' Guid='PUT-GUID-HERE' DiskId='1'> <File Id='ExampleFile' Name='example.txt' Source='example.txt'> <Shortcut Id='ExampleShortcut' Directory='ProgramMenuFolder' Name='Example Shortcut' Description='Shortcut to example.txt'/> </File> &nb
sp; </Component> </Directory> </Directory> </Directory> <Directory Id='ProgramMenuFolder' Name='ProgMenu'/> </Directory> <Feature Id='ExampleFeature' Title='Example Feature for Product' Level='1'> <ComponentRef Id='ExampleComponent' /> </Feature> </Product> </Wix> Note, to compile the code above with candle.exe, you'll need to replace "PUT-GUID-HERE" with your own GUID. I don't provide GUIDs in my examples because people like to copy the examples then forget to change the GUID before shipping. Of course, that would be an immediate Component Rule violation and I don't want to be responsible for that. Also, before we can link that code with light.exe, we'll need to create a text file called, "example.txt". Here's what my example.txt file looks like: Each day is a gift, that's why we call it the present. Okay, after creating example.wxs (and adding your own GUID) and creating example.txt, you should be able to create an "example.msi" file by compiling and linking the files like so: C:\wix>candle example.wxs Microsoft (R) Windows Installer Xml Compiler version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. example.wxs C:\wix>light example.wixobj Microsoft (R) Windows Installer Xml Linker version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\wix> As always, no news f
rom light.exe is good news. You can install the newly created MSI file using "msiexec /i example.msi" and should notice a new shortcut in your ProgramMenuFolder ("Start" -> "All Programs" on Windows XP). But I'm sure for you old WiX toolset hacks out there this example is boring. So, let's get to localizing. If you used the preprocessor, you are already familiar with $(var.VAR) for defined variables and $(env.VAR) for environment variables. Localization in the WiX toolset is done by inserting "localization variables". Localization variables look like !(loc.VAR). Let's look at our modified source file: <?xml version='1.0'?> <Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'> <Product Id='*' Name='ExampleProduct' Language='!(loc.LANG)' Version='1.0.0.0' Manufacturer='Microsoft Corporation'> <Package
Description='!(loc.Description)' Comments='!(loc.Comments)' InstallerVersion='200' Compressed='yes' /> <Media Id='1' Cabinet='product.cab' EmbedCab='yes' /> <Directory Id='TARGETDIR' Name='SourceDir'> <Directory Id='ProgramFilesFolder' Name='PFiles'> <Directory Id='EXAMPLEDIR' Name='!(loc.LongDirName)'> <Directory Id='LangDir' Name='!(loc.LANG)'> <Component Id='ExampleComponent' Guid='PUT-GUID-HERE' DiskId='1'> <File Id='ExampleFile' Name='!(l
oc.FileName)' Source='example.txt'> <Shortcut Id='ExampleShortcut' Directory='ProgramMenuFolder' Name='!(loc.ShortShortcutName)' Description='!(loc.LongShortcutName)'/> </File> </Component> </Directory> </Directory>
; </Directory> <Directory Id='ProgramMenuFolder' Name='ProgMenu'/> </Directory> <Feature Id='ExampleFeature' Title='!(loc.FeatureTitle)' Level='1'> <ComponentRef Id='ExampleComponent' /> </Feature> </Product> </Wix> You should again be able to compile that file but if you try to link you should see error messages such as, "light.exe : fatal error LGHT0023: Localization string 'FeatureTitle' unknown. Ensure that the !(loc.FeatureTitle) is defined." That error message basically means we did not provide a Localization file with all of the localizable identifiers and text. So, now we need to create our first .wxl file. I've called mine example1033.wxl and it goes a little like this: <?xml version='1.0'?> <WixLocalization xmlns='http://schemas.microsoft.com/wix/2006/localization' Codepage='1252'> <String Id='LANG'>1033</String> <String Id='Description'>Example Description for Product</String> <String Id='Comments'>Example Product to demonstrate localized Data</String> <String Id='ShortDirName'>example</String> <String Id='LongDirName'>Example Directory</String> <String Id='Filename'>example.txt</String> <String Id='ShortShortcutName'>Example</String> <String Id='LongShortcutName'>Shortcut to example.txt</String> <String Id='FeatureTitle'>Example Feature for Product</String> </WixLocalization> Now, to get our MSI file back. C:\wix>candle example.wxs Microsoft (R) Windows Installer Xml Compi
ler version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. example.wxs C:\wix>light example.wixobj -loc example1033.wxl Microsoft (R) Windows Installer Xml Linker version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\wix> I want to note that (barring any typos) this MSI file should be identical to the first MSI file we created. I also want to note that this will be the last time we compile the example.wxs. Since we have specified all of our localization variables we no longer need to compile to get changes in our MSI file. All we need to do localize our example1033.wxl file into other languages. Since, I don't know any other languages, I'm going to localize our example1033.wxl file into the "Foo language" and use the Japanese LCID, 1041, since I happen to remember that one. Here's the example1041.wxl file local
ized into the "Foo language": <?xml version='1.0'?> <WixLocalization xmlns='http://schemas.microsoft.com/wix/2006/localization' Codepage='932'> <String Id='LANGID'>1041</String> <String Id='Description'>Foo Foo foo Foo</String> <String Id='Comments'>Foo Foo foo foo foo Foo</String> <String Id='ShortDirName'>Foo</String> <String Id='LongDirName'>Foo Foo</String> <String Id='Filename'>foo.txt</String> <String Id='ShortShortcutName'>Foo</String> <String Id='LongShortcutName'>Foo foo foo.txt</String> <String Id='FeatureTitle'>Foo Foo foo Foo</String> </WixLocalization> Notice how elegant the "Foo language" is. The elegance really is lost in text format. So much of the "Foo language" is trans
mitted via the pitch and duration of each word. But I digress. Let's build our "Foo language" example.msi file. This will just stomp over our previous example.msi so make sure you uninstall the previous example.msi file using "msiexec /x example.msi" (or you'll have to go to Control Panel -> Add/Remove Programs). Let's link (and only link) our MSI file: C:\wix>light example.wixobj -loc example1041.wxl Microsoft (R) Windows Installer Xml Linker version 2.0.2328.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\wix> Now if you install the MSI file you are likely to see square boxes for the ActionText during the progress dialog box. I believe this occurs when you don't have the Japanese fonts necessary to display the Windows Installer's default text messages. In any case, I don't have Japanese fonts installed on my machine so I see square boxes. However, squar
e boxes or no square boxes everything should install just fine. After installing, you too should see a "Foo" shortcut in your ProgramMenuFolder. That's all there is to .wxl files. Hopefully, you can see how the Localization files can greatly simplify the relationship between you, your localizers, and your setup. I would also like to note that .wxl files are relatively new constructs in the WiX toolset so if you have suggestions how to improve them please feel free to send your feedback to the "wix-devs at sourceforge.net" mailing list. And that brings me to my final point. There is one very fatal flaw in the code above. I debated delaying this blog entry to fix the issue but decided the content here was valuable even with the mistake. Have you found it yet? Look closely at the Component/@Guid attribute. Did that value change each time you created a completely different Component like the step 9 in the Localization Overview suggests? Probably not because you can't currently localize GUID values as described by this bug on SourceForge. However, the value should change because you have very different Shortcuts in the two Components (and the example.txt file is installed to different locations so there is no overlap). So, I apologize profusely for creating an example that violates the Component Rules and I will fix the bug ASAP. In the meantime, have fun playing with your .wxl files and keep coding.
Copyright © Rob Mensching

--- NEW FILE: votive_wix_references.htm ---

Votive WiX References

Votive WiX References
Introduction

Votive supports adding references to WiX libraries and extensions in a WiX project. Adding references to libraries and extensions allows you to reference WiX elements (such as custom actions and properties) defined in those libraries and extensions without needing to duplicate the functionality in your own authoring.
When adding a WiX reference, Votive will automatically add the necessary parameters to the compiler and linker command lines so that the references will be correctly resolved when building a WiX project.

Adding WiX References

To add a WiX library or extension DLL reference to a WiX project in the Visual Studio IDE:

Right-click on the References node for the WiX project in the Visual Studio Solution Explorer and choose Add Reference...
In the Add WiX Library Reference dialog, click on the Browse tab
Locate the desired .wixlib files and WiX extension DLLs and click the Add button, then click OK to dismiss the dialog

--- NEW FILE: lit.htm ---

Library Tool (lit)

Library Tool (lit)

Lit is the WiX library creation tool. It can be used to combine multiple .wixobj files into libraries that can be consumed by light.

Additional Topics

Lit usage information

Index: authoring_merge_modules.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/authoring_merge_modules.htm,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** authoring_merge_modules.htm 19 Jul 2006 05:54:26 -0000 1.3
--- authoring_merge_modules.htm 27 Jun 2007 05:36:13 -0000 1.4
***************
*** 48,52 ****
<Directory Id='MyModuleDirectory' Name='.'>
<Component Id='MyModuleComponent' Guid='87654321-4321-4321-4321-110987654321'>
! <File Id='readme2' Name='readme2.txt' src='readme2.txt' />
</Component>
</Directory>
--- 48,52 ----
<Directory Id='MyModuleDirectory' Name='.'>
<Component Id='MyModuleComponent' Guid='87654321-4321-4321-4321-110987654321'>
! <File Id='readme2' Name='readme2.txt' Source='readme2.txt' />
</Component>
</Directory>
***************
*** 81,88 ****
<Directory Id='MyDir' Name='Test Program'>
<Component Id='MyComponent' Guid='12345678-1234-1234-1234-123456789012'>
! <File Id='readme' Name='readme.txt' DiskId='1' src='readme.txt' />
</Component>

! <Merge Id='MyModule' Language='1033' src='module.msm' DiskId='1' />
</Directory>
</Directory>
--- 81,88 ----
<Directory Id='MyDir' Name='Test Program'>
<Component Id='MyComponent' Guid='12345678-1234-1234-1234-123456789012'>
! <File Id='readme' Name='readme.txt' DiskId='1' Source='readme.txt' />
</Component>

! <Merge Id='MyModule' Language='1033' SourceFile='module.msm' DiskId='1' />
</Directory>
</Directory>

--- NEW FILE: lit_usage.htm ---

Lit usage

Lit usage

Lit usage:

lit.exe [-?] [-nologo] [-out libraryFile] objectFile [objectFile ...]

Lit supports the following command line parameters:

Switch

Meaning

-b

Specify a base path to locate all files; the default value is the current working directory

-bf

Bind files into the library file

-ext

Specify an extension assembly

-loc <loc.wxl>

Provide a .wxl file to read localization strings from

-nologo

Skip printing Lit logo information

-out

Specify an output file; by default, Lit will write to the current working directory

-ss

Suppress schema validation for documents; this switch provides a performance boost during linking

-sv

Suppress intermediate file version mismatch checking

-sw<N>

Suppress warnings with specific message IDs

-v

Generate verbose output

-wx

Treat warnings as errors

-?

Display Lit help information

--- NEW FILE: votive_project_references.htm ---

Votive Project References

Votive Project References
Introduction

Votive supports adding project references to a WiX project. Adding project references will ensure that build order dependencies are defined correctly within the solution. In addition, Votive will generate a set of WiX preprocessor definitions that are set on the Candle command line and can be referenced in the files in the WiX project.

Adding Project References

To add a project reference to a WiX project in the Visual Studio IDE:

Right-click on the References node for the WiX project in the Visual Studio Solution Explorer and choose Add Reference...
In the Add WiX Library Reference dialog, click on the Projects tab
Select the desired project(s) and click the Add button, then click OK to dismiss the dialog

List of Supported Project References

Votive supports the following project reference variables:

Variable name

Example usage

Example value

var.<ProjectName>.Configuration

$(var.MyProject.Configuration)

Debug or Release

var.<ProjectName>.FullConfiguration

$(var.MyProject.FullConfiguration)

Debug | AnyCPU

var.<ProjectName>.Platform

$(var.MyProject.Platform)

AnyCPU, Win32, x64 or ia64

var.<ProjectName>.ProjectDir

$(var.MyProject.ProjectDir)

C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\

var.<ProjectName>.ProjectExt

$(var.MyProject.ProjectExt)

.csproj

var.<ProjectName>.ProjectFileName

$(var.MyProject.ProjectFileName)

MyProject.csproj

var.<ProjectName>.ProjectName

$(var.MyProject.ProjectName)

MyProject

var.<ProjectName>.ProjectPath

$(var.MyProject.ProjectPath)

C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\MyApp.csproj

var.<ProjectName>.TargetDir

$(var.MyProject.TargetDir)

C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\obj\Debug\

var.<ProjectName>.TargetExt

$(var.MyProject.TargetExt)

.exe

var.<ProjectName>.TargetFileName

$(var.MyProject.TargetFileName)

MyProject.exe

var.<ProjectName>.TargetName

$(var.MyProject.TargetName)

MyProject

var.<ProjectName>.TargetPath

$(var.MyProject.TargetPath)

C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\obj\Debug\MyProject.exe

var.SolutionDir

$(var.SolutionDir)

C:\users\myusername\Documents\Visual Studio 2005\Projects\MySolution\

var.SolutionExt

$(var.SolutionExt)

.sln

var.SolutionFileName

$(var.SolutionFileName)

MySolution.sln

var.SolutionName

$(var.SolutionName)

MySolution

var.SolutionPath

$(var.SolutionPath)

C:\users\myusername\Documents\Visual Studio 2005\Projects\MySolution\MySolution.sln

Example

The following File element demonstrates how to use project references in WiX authoring:

<File Id="MyExecutable" Name="$(var.MyProject.TargetFileName)" Source="$(var.MyProject.TargetPath)" DiskId="1" />

Index: preprocessor.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/preprocessor.htm,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** preprocessor.htm 7 Nov 2005 22:47:30 -0000 1.1
--- preprocessor.htm 27 Jun 2007 05:36:14 -0000 1.2
***************
*** 182,185 ****
--- 182,195 ----

+ Errors and Warnings
+ You can use the preprocessor to show meaningful error and warning messages using, <?error error-message ?> and <?warning warning-message?>. When one of these preprocessor instructions is encountered the preprocessor will either display an error and stop the compile or display a warning and continue.
+
+ An example:
+
+ <?ifndef RequiredVariable ?>
+ <?error RequiredVariable must be defined ?>
+ <?endif?>
+
+
Iteration Statements
There is a single iteration statement, <?foreach variable-name in

Index: wxs.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/wxs.htm,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** wxs.htm 7 Nov 2005 22:47:30 -0000 1.1
--- wxs.htm 27 Jun 2007 05:36:14 -0000 1.2
***************
*** 7,20 ****
Source Files (.wxs)

! All .wxs files are well-formed XML documents that contain a single root element named . The rest of the source file may or may not adhere to the WiX schema before preprocessing. However, after being preprocessed all source files must conform to the WiX schema or they will fail to compile.

! The root element can contain at most one of the following two elements as children: , . However, there can be an unbounded number elements as children of the root element. When a source file is compiled into an object file, each instance of these elements creates a new section in the object file. Therefore, these three elements are often referred to as section elements.

! It is important to note, that there can be only one or section element per source file because they are compiled into special sections called entry sections. Entry sections are used as starting points in the linking process. Sections, entry sections, and the entire linking process are described in greater detail later in this document.

! The children of the section elements define the contents of the Windows Installer database. You’ll recognize elements that map to entries in the Property table and a hierarchy of elements that build up the Directory table. Most elements contain an “Id” attribute that will act as the primary key for the resulting row in the Windows Installer database. Note, in the first release of the WiX schema the primary key was represented by the text of the element. This location for the primary key was undesirable for several reasons and has been moved to the “Id” attribute. In most cases, the “Id” attribute also defines a symbol when the source file is compiled into an object file.

--- 7,20 ----
Source Files (.wxs)

! All .wxs files are well-formed XML documents that contain a single root element named <Wix/>. The rest of the source file may or may not adhere to the WiX schema before preprocessing. However, after being preprocessed all source files must conform to the WiX schema or they will fail to compile.

! The root <Wix/> element can contain at most one of the following two elements as children: <Product/>, <Module/>. However, there can be an unbounded number <Fragment/> elements as children of the root <Wix/> element. When a source file is compiled into an object file, each instance of these elements creates a new section in the object file. Therefore, these three elements are often referred to as section elements.

! It is important to note, that there can be only one <Product/> or <Module/> section element per source file because they are compiled into special sections called entry sections. Entry sections are used as starting points in the linking process. Sections, entry sections, and the entire linking process are described in greater detail later in this document.

! The children of the section elements define the contents of the Windows Installer database. You’ll recognize <Property/> elements that map to entries in the Property table and a hierarchy of <Directory/> elements that build up the Directory table. Most elements contain an “Id” attribute that will act as the primary key for the resulting row in the Windows Installer database. Note, in the first release of the WiX schema the primary key was represented by the text of the element. This location for the primary key was undesirable for several reasons and has been moved to the “Id” attribute. In most cases, the “Id” attribute also defines a symbol when the source file is compiled into an object file.

Index: votive.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/votive.htm,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** votive.htm 7 Nov 2005 22:47:30 -0000 1.1
--- votive.htm 27 Jun 2007 05:36:14 -0000 1.2
***************
*** 8,38 ****

Votive is the code name for the WiX Visual Studio package that allows you to easily create WiX projects, edit WiX files using IntelliSense, and
! compile/link your project.

Installation

! To install the package you must run Votive.msi, which comes bundled with the WiX binaries and gets built as part of the WiX source.

! If you have the VSIP SDK installed, you can build the the debug version of Votive.msi, which will install Votive into the Experimental Hive of Visual Studio.
! This will allow your retail version of Visual Studio to continue to work as before (see the "Developing for Votive" topic for an explanation of the
! experimental hive).

- Developing for Votive
-
- If you want to contribute code to the Votive project or debug Votive, you must download and install the VSIP SDK, available at http://www.vsipdev.com/downloads/. You will need the VSIP SDK 2003 and the VSIP SDK 2003 Extras, installed in that order. The SDK is fairly
- non-invasive and will create an "Experimental Hive" in the registry that will keep your retail version of Visual Studio 2003 unaffected.

!
! To start debugging Votive, set your breakpoints then just hit "F5" in the Wix.sln for Visual Studio. The custom build actions in the Votive project will set up
! and register Votive on the experimental hive, so running the Votive.msi is not required, nor suggested.
!
! Getting Started

Rob Mensching has written an excellent MSDN article on using Votive to get started in WiX.

!

--- 8,37 ----

Votive is the code name for the WiX Visual Studio package that allows you to easily create WiX projects, edit WiX files using IntelliSense, and
! compile/link your project within the Visual Studio 2005 IDE or via command line using MSBuild.

Installation

! To install the package you must run Wix3.msi on a computer that has Visual Studio 2005 Standard Edition or higher installed.

! If you have the VSIP SDK installed, you can build the the debug version of Wix3.msi, which will install Votive into the Experimental hive of Visual Studio 2005.
! This will allow your retail version of Visual Studio to continue to work as before. See the Developing for Votive topic for an explanation of the
! experimental hive.

! Getting started

Rob Mensching has written an excellent MSDN article on using Votive to get started in WiX.

! Votive topics
!
! Project templates
! Item templates
! Project property pages
! Project references
! WiX references
! Developing for Votive
!

--- NEW FILE: votive_development.htm ---

Developing for Votive

Developing for Votive

If you want to contribute code to the Votive project or debug Votive, you must download and install the Visual Studio 2005 SDK, available at the Visual Studio Extensibility Developer Center. The Visual Studio 2005 SDK is non-invasive and will create an experimental hive in the registry that will leave your retail version of Visual Studio 2005 unaffected.

To start debugging Votive, set your breakpoints then press F5 in the Wix.sln for Visual Studio. The custom build actions in the Votive project will set up
and register Votive in the experimental hive, so running Wix3.msi is not required, nor suggested.

Index: perfmon.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/perfmon.htm,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** perfmon.htm 19 Jul 2006 05:54:26 -0000 1.3
--- perfmon.htm 27 Jun 2007 05:36:14 -0000 1.4
***************
*** 48,55 ****
<Registry Id="Shared_r4" Root="HKLM" Key="SYSTEM\CurrentControlSet\Services\MyApplication\Performance" Name="Library" Value="[!PERFDLL.DLL]" Type="string" />

! <File Id="PERFDLL.DLL" Name="MyPerfDll.dll" src="x86\debug\0\myperfdll.dll" />

! <File Id="PERFCOUNTERS.H" Name="PerfCounters.h" src="x86\debug\0\perfcounters.h" />
! <File Id="PERFCOUNTERS.INI" Name="PerfCounters.ini" src="x86\debug\0\perfcounters.ini" >
<PerfCounter Name="MyApplication" />
</File>
--- 48,55 ----
<Registry Id="Shared_r4" Root="HKLM" Key="SYSTEM\CurrentControlSet\Services\MyApplication\Performance" Name="Library" Value="[!PERFDLL.DLL]" Type="string" />

! <File Id="PERFDLL.DLL" Name="MyPerfDll.dll" Source="x86\debug\0\myperfdll.dll" />

! <File Id="PERFCOUNTERS.H" Name="PerfCounters.h" Source="x86\debug\0\perfcounters.h" />
! <File Id="PERFCOUNTERS.INI" Name="PerfCounters.ini" Source="x86\debug\0\perfcounters.ini" >
<PerfCounter Name="MyApplication" />
</File>

Index: patch_building.htm
===================================================================
RCS file: /cvsroot/wix/wix/src/chm/html/patch_building.htm,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** patch_building.htm 19 Jul 2006 05:54:26 -0000 1.3
--- patch_building.htm 27 Jun 2007 05:36:14 -0000 1.4
***************
*** 75,80 ****
<Family DiskId="2" MediaSrcProp="insert-product-abbreviaiton-hereprop_2_1_01"
Name="insert-organization-name-here and insert-product-abbreviaiton-here1" SequenceStart="1010">
! <UpgradeImage src="$(var.Proj2)\Installer.msi" Id="insert-product-abbreviaiton-hereUpgrade">
! <TargetImage src="$(var.Proj1)\Installer.msi" Order="2"
Id="insert-product-abbreviaiton-hereTarget" IgnoreMissingFiles="no" />
</UpgradeImage>
--- 75,80 ----
<Family DiskId="2" MediaSrcProp="insert-product-abbreviaiton-hereprop_2_1_01"
Name="insert-organization-name-here and insert-product-abbreviaiton-here1" SequenceStart="1010">
! <UpgradeImage SourceFile="$(var.Proj2)\Installer.msi" Id="insert-product-abbreviaiton-hereUpgrade">
! <TargetImage SourceFile="$(var.Proj1)\Installer.msi" Order="2"
Id="insert-product-abbreviaiton-hereTarget" IgnoreMissingFiles="no" />
</UpgradeImage>

--- NEW FILE: votive_item_templates.htm ---

Votive Item Templates

Votive Item Templates

Votive provides the following item templates:

WiX File - a .wxs file pre-populated with the same information as the default WXS file in a WiX Library Project
WiX Product File - a .wxs file pre-populated with the same information as the default WXS file in a WiX Project
WiX Include File - a blank .wxi file
WiX Merge Module File - a .wxs file pre-populated with the same information as the default WXS file in a WiX Merge Module Project
WiX Localization File - a blank .wxl file

To add a new item template to a WiX project, right-click on the WiX project in the Visual Studio solution explorer, choose Add | New Item... and select the appropriate item template.

------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

------------------------------

_______________________________________________
Wix-commits mailing list
Wix-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-commits

End of Wix-commits Digest, Vol 11, Issue 31
*******************************************

2007 27 июня

Бизнес
робот

Темы:

Архив:

Каталог рекламы и объявлений