C# (CSharp) WixSharp 네임스페이스

This class does not contain any public constructor and is only to be used as a base class for deriving specialized CustomActions (e.g. ) or for declaring heterogeneous collections.

This class is essentially the same as except it has extra member RegisterInGAC to define if the assembly file needs to be registered in GAC during the installation.

- You must set KeyPath you install in the user profile.

- You must use a registry key under HKCU as component's KeyPath, not a file.

- The Component element cannot have multiple key path set.

- The project must have at least one directory element.

- All directories installed in the user profile must have corresponding RemoveDirectory elements.

...

The MSI always wants registry keys as the key paths for per-user components. It has to do with the way profiles work with advertised content in enterprise deployments. The fact that you do not want to install any registry doesn't matter. MSI is the boss.

The following link is a good example of the technique: http://stackoverflow.com/questions/16119708/component-testcomp-installs-to-user-profile-it-must-use-a-registry-key-under-hk

You can use this class to embed any file (e.g. exe, dll, image) to be used during the installation. Note that none of the binary files are installed on the target system. They are just available at installation time for using CustomActions.

Condition is nothing else but an XML friendly string wrapper, containing some predefined (commonly used) condition values. You can either use one of the predefined condition values (static members) or define your by specifying full string representation of the required WiX condition when calling the constructor or static method Create.

Use this class to define file/directory structure of the deployment solution.

Wix# - WiX

%WindowsFolder% - [WindowsFolder]

%ProgramFiles% - [ProgramFilesFolder]

%ProgramMenu% - [ProgramMenuFolder]

%AppDataFolder% - [AppDataFolder]

%CommonFilesFolder% - [CommonFilesFolder]

%LocalAppDataFolder% - [LocalAppDataFolder]

%ProgramFiles64Folder% - [ProgramFiles64Folder]

%System64Folder% - [System64Folder]

%SystemFolder% - [SystemFolder]

%TempFolder% - [TempFolder]

%Desktop% - [DesktopFolder]

Use this class to define files to be automatically included into the deployment solution if their name matches specified wildcard character pattern (DirFiles.IncludeMask).

You can use DirFiles.ExcludeMasks to exclude certain files from setup if required.

This class is a logical equivalent of Files except that it analyses files in a single directory.

Any CustomAction, which needs elevation must be run with Action.Impersonate set to false and Action.Execute set to Execute.deferred. Thus ElevatedManagedAction is a full equivalent of T:WixSharp.ManagedAction with appropriately adjusted Action.Execute and Action.Impersonate during the instantiation:

You can use this class to embed any .NET assembly to be used during the installation. Note that none of the binary files are installed on the target system. They are just available at installation time for using CustomActions.

ExeFileShortcut is a specialized version of the Shortcut designed for using Shortcut as a Dir nested element

There are different ways of defining shortcuts of the Wix# project:

- It can be specified as a nested element of the File. In this case after the installation the shortcut will point to the file it belongs to.

- Alternatively the Shortcut can be specified as a Dir nested element. In this case after the installation the shortcut will point to the file it belongs to.

All installable WiX components belong to one or more features. By default, if no Features are defined by user, Wix# creates "Complete" feature, which contains all installable components.

FileShortcut is a specialized version of the Shortcut designed for using Shortcut as a File nested element.

There are different ways of defining shortcuts of the Wix# project:

- It can be specified as a nested element of the File. In this case, after the installation, the shortcut will point to the file it belongs to.

- Alternatively the Shortcut can be specified as a File nested element. In this case after the installation the shortcut will point to the file will point to the file it belongs to.

Use this class to define files to be automatically included into the deployment solution if their name matches specified wildcard character pattern (Files.IncludeMask).

You can use Files.ExcludeMasks to exclude certain files from setup if required.

This class is a logical equivalent of DirFiles except it also analyses all files in all subdirectories. DirFiles excludes files in subdirectories.

Id is used to "stamp" every XML element of the WiX source file produced by Wix#.

Condition is nothing else but an XML friendly string wrapper, containing some predefined (commonly used) condition values. You can either use one of the predefined condition values (static members) or define your by specifying full string representation of the required WiX condition when calling the constructor or static method Create.

Managed CustomAction can be defined either in the Wix# script or in the external assembly or C# file. The only requirements for any C# method to be qualified for being Managed CustomAcyion is to have DTF Action signature public static ActionResult MyManagedAction(Session session), and be marked with [CustomAction] attribute.

If Managed CustomAction depends on any assembly, which will not be registered with GAC on the target system such assembly needs to be listed in the ManagedAction.RefAssemblies.

Note that WiX syntax allows Merge element to belong to the Product element. However the documentation (WiX v3.0.4917.0) explicitly requires it to be nested inside of the Directory element (even if there is no neither technical nor logical reason for this). Thus Wix# simply follows the WiX convention.

Project instance can be compiled into complete MSI or WiX source file with one of the Compiler "Build" methods.

Use Project non-default constructor or C# initializers to specify required installation components.

Traditional property usage involves defining the property by instantiating the Property class (in the Project structure) and then setting it from CustomAction (e.g. SetPropertyAction).

Property value can be analyzed and used in CustomActions or it can be a base for the Condition of item to be installed.

Sometimes it desirable to access WiX properties defined in the extension modules. PropertyRef is designed for such cases. You can use it as an ordinary WiX property but you do not need to set it up (e.g. define initial value) as it is already done in the corresponding extension module.

In a way PropertyRef is similar to C++ #include as it makes possible to access some entities defined in the external modules.

QtCmdLineAction executes specified application with optional arguments. You do not have to specify full path to the application to be executed as long as its directory is well-known (e.g. listed in system environment variable PATH) on the target system.

Compiler uses the data from this class to call T:WixSharp.CommonTasks.ImportRegFile internally and inject imported RegValues into the Project.

RegValueProperty is used to set a property from the registry value when accessing the registry is inconvenient for a custom action.

RegistrySearch returns raw data thus data will always contain prefix indicating data type:

DWORD: Starts with '#' optionally followed by '+' or '-'.

REG_BINARY: Starts with '#x' and the installer converts and saves each hexadecimal digit (nibble) as an ASCII character prefixed by '#x'.

REG_EXPAND_SZ: Starts with '#%'.

REG_MULTI_SZ: Starts with '[~]' and ends with '[~]'.

REG_SZ: No prefix, but if the first character of the registry value is '#', the installer escapes the character by prefixing it with another '#'.

Before or After switch for Custom Action is controlled by When.

Version is represented as a string to allow for predefined value %this%, which means "version of the product MSI being built".

This class includes predefined ranges for common upgrade scenarios.

As opposite to the WixSharp.T:WixSharp.WixForm based custom dialogs WixCLRDialog is instantiated not at compile but at run time. Thus it is possible to implement comprehensive deployment algorithms in any of the available Form event handlers.

The usual usability scenario is the injection of the managed Custom Action (for displaying the WixCLRDialog) into the sequence of the standard dialogs (WixSharp.T:WixSharp.CustomUI).

While it is possible to construct T:WixSharp.CustomUI instance manually it is preferred to use Factory methods of T:WixSharp.CustomUIBuilder (e.g. InjectPostLicenseClrDialog) for this.

The all communications with the installation in progress are to be done by modifying the MSI properties or executing MSI actions via Session object.

When closing the dialog make sure you set the DeialogResul properly. WixCLRDialog offers three predefined routines for setting the DialogResult:

- MSINext

- MSIBack

- MSICancel

Based on http://developmenttips.blogspot.com/2008/03/generate-sequential-guids-for-sql.html

This class is used by Wix# engine internally to emit reproducible WiX code.