Export (0) Print
Expand All
3 out of 20 rated this helpful - Rate this topic

Tutorial: Installing Controls By Using the Toolbox Controls Installer

Visual Studio 2005
[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

This tutorial explains how to use the Toolbox Controls Installer (TCI). When you have finished this tutorial, you will have created full-featured installers for both Windows Forms controls and Web Forms controls that you can install into the Visual Studio Toolbox by using the Toolbox Controls Installer (TCI). You will be able to install and uninstall them by using both a graphical user interface and the command line. The sample controls are located in <Visual Studio SDK installation path>\VisualStudioIntegration\Samples\Controls\, in subdirectories named WinControl and WebControl. The installers are located in a subdirectory named Setup, one for each sample control.

The source code for each step in this tutorial is available in a separate file in the Setup directories. You can follow along without having to type or copy and paste the source code.

The installers in this tutorial are built by using version 2 of the WiX toolset. The Visual Studio SDK includes a subset of a version 2 release of WiX. You can download a complete release to get additional tools and documentation.

Installing a Windows Forms Control

In this section, you will create an installer that does the following:

  • Installs the WinControl sample control into the global assembly cache (GAC).

  • Registers the control with TCI for Visual Studio and Visual Studio Express Edition products.

  • Uses TCI custom actions to notify TCI that the Visual Studio Toolbox must be updated with the new control.

Let's divide this section into five steps, as follows:

  • Step 1: A Do-Nothing Installer Template. In this step, you will create a basic installer template.

  • Step 2: Install the Windows Forms Control in the Global Assembly Cache (GAC).

  • Step 3: Check for the TCI. You will make sure that the TCI package, which handles registration of controls in the Visual Studio Toolbox, is installed.

  • Step 4: Register the Control with the TCI.

  • Step 5: Add Optional Support for Visual Studio Express Edition Products.

Step 1: A Do-Nothing Installer Template

In this first step, you'll create the installer equivalent of “Hello World;” that is, you'll create the basic scaffolding that you’ll add real functionality to later.

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Sample Controls Installer
  Installs and registers controls with ToolboxControlsInstaller
-->

<?define ProductShortName = "Litware Sample WinForms Control" ?> 
<?define ProductVersion = "1.0.0" ?>
<?define ProductVersionText = "1.0" ?>
<?define Manufacturer = "Litware, Inc." ?>
<?define ProductCode = "9698E669-2D4F-4777-94E0-259C33CA1E09" ?>
<?define UpgradeCode = "A3E57B39-F1E3-466b-BFE9-8702FE748CC2" ?>

The source code starts out by defining some preprocessor variables. Like constants and macros in other languages, WiX preprocessor variables let you define symbolic names for values that you use or frequently change. In this case, preprocessor variables hold product name and version information so that they are consistent. Other preprocessor variables hold GUIDs for the installer. ProductCode identifies a particular version of the product to be installed. UpgradeCode identifies a family of related products. Later steps in this tutorial will use the upgrade code to enable newer product releases to upgrade older versions.

<Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
  <Product Id="$(var.ProductCode)"
           UpgradeCode="$(var.UpgradeCode)"
           Name="$(var.ProductShortName) $(var.ProductVersionText)"
           Version="$(var.ProductVersion)"
           Language="1033"
           Manufacturer="$(var.Manufacturer)">

The root element of every WiX source file is the Wix element. The Product element tells the WiX toolset to create an installer package, which is a file that has an .msi extension. Attributes on the Product element identify the product, mostly by using the preprocessor variables defined earlier. The Name, Version, and Manufacturer attribute values are shown in the Add or Remove Programs Control Panel application.

<Package Id="????????-????-????-????-????????????"
         Compressed="yes"
         Description="$(var.ProductShortName) $(var.ProductVersionText) ($(var.ProductVersion))"
         InstallerVersion="200" />
<Media Id="1"
       Cabinet="SampleControls.cab"
       EmbedCab="yes" />

The Package element contains attributes that are specific to the .msi file. The Id attribute value of all question marks tells WiX to generate a new GUID for the package code each time the package is compiled. Because Windows Installer uses the package code as the primary identifier for packages, each packages must have a unique package code. By generating a new package code every time that you compile, you guarantee compliance with that rule.

NoteNote

In this tutorial and in other discussions of Windows Installer, the term “package” refers to a Windows Installer database, either an .msm merge module or an .msi installer. It has nothing to do with VSPackages.

The Compressed attribute indicates that the files that make up the package are compressed. (We will add files later.) Description is a string that is shown in Windows Explorer properties windows and infotips. It is not shown in the Add or Remove Programs Control Panel application. InstallerVersion lets you specify the minimum required version of Windows Installer. In this case, 200 means Windows Installer 2.0.

The Media element describes how the files in the installer package will be stored. By specifying the Cabinet and EmbedCab attributes, WiX creates a compressed .cab file and embeds it in the .msi file.

    <!-- Properties -->
    <Property Id="ALLUSERS"
              Value="1" />

This Property element creates a property named ALLUSERS with a value of 1. An ALLUSERS value of 1 tells Windows Installer to install the product for all users of the destination computer. It’s possible to install products for individual users, but because the sample Windows Forms control is installed to the GAC, the installing user must have administrator permissions anyway. Therefore, there’s no advantage to programming a per-user installation.

    <!-- Launch conditions -->
    <Condition Message="An administrator must approve or install [ProductName]."> Privileged </Condition>

Also, because the installing user must have administrator privileges, a launch condition makes sure that a non-administrator user can’t run the installer. The Condition element uses the Privileged property to determine the user’s rights level.

NoteNote

On Windows Vista, the Privileged property is set even when the user’s account is a standard account or protected-administrator account. That means that on Windows Vista, the launch condition will always be true. After the user has followed the installer’s wizard UI and Windows Installer is ready to modify the system, a standard account or protected-administrator account receives a prompt to elevate privileges. After getting permission from the user, Windows Installer uses administrator privileges to modify protected parts of the system. If the user doesn’t give permission, the installation will continue but fail. Later steps in this tutorial explicitly address Windows Vista compatibility.

    <!-- User interface -->
    <UIRef Id="WixUI_Minimal" />
  </Product>
</Wix>

The UIRef element creates a reference to the WixUI_Minimal dialog set. As you can guess from its name, WixUI_Minimal is a minimal set of wizard UI pages. The first page displays a license agreement and a button to install the product. When you call the WiX linker (light.exe), you must supply the WixUI library file name and a set of localization strings. The setup.proj MSBuild project file item for the Step 1 source code looks like this:

<Exec Command="$(WixDir)\light.exe Step1.wixobj $(WixDir)\wixui.wixlib -out Step1.msi -loc $(WixDir)\WixUI_en-us.wxl" />

Checkpoint

You can test the installer scaffolding by running the following commands at the command prompt in the <Visual Studio SDK installation path>\VisualStudioIntegration\Samples\Controls\WinForms\Setup\ directory:

Command Description

msbuild setup.proj

Builds the Windows Forms control and installers.

msiexec /i Step1.msi

Installs the Step 1 scaffolding. To verify that it installed successfully, open the Add or Remove Programs Control Panel application. Because the scaffolding installs no files and creates no registry entries, it’s not otherwise visible on the system.

msiexec /x Step1.msi

Uninstalls the Step 1 scaffolding.

Step 2: Install the Windows Forms Control in the Global Assembly Cache

Now we’re ready to actually install some files, specifically, the Windows Forms control that is installed to the GAC. However, first we must discuss two higher-level Windows Installer concepts: components and features.

A component is the Windows Installer unit of atomic installation. Components consist of related resources like files and registry values. Each component is in a single folder; in this case, it’s the “virtual” folder of the GAC.

Features consist of components and are often exposed to the user as a tree of items that can be installed or removed. At least one feature is required.

In this step, source code that was changed or added since Step 1 is shown in bold. Code that didn’t change isn’t shown, except to provide context for the changed or added code.

…
    <!-- Properties -->
    <Property Id="ALLUSERS"
              Value="1" />

    <!-- Launch conditions -->
    <Condition Message="An administrator must approve or install [ProductName]."> Privileged </Condition>

    <!-- Features -->
    <Feature Id="LitwareCtrls"
             Level="1"
             Title="Litware Controls"
             Description="Litware Controls"
             Display="expand"
             AllowAdvertise="no"
             InstallDefault="local"
             Absent="disallow">
      <ComponentRef Id="LitwareWinControl_Component" />
    </Feature>

This table describes the attributes used in the Feature element:

Attribute Description

Id

Every feature must have an ID that’s unique to the .msi package.

Level

Sets the installation level of the feature. The lower the installation level, the higher its priority. In this case, a “1” level means it will always be installed.

Title

A short feature title. It’s shown in the typical feature-selection tree control in the installer user interface.

Description

A longer feature description. Most installer UIs show several lines of the feature description.

Display

A Display value of “expand” means that the feature is visible and if it had child features, they’d be visible too.

AllowAdvertise

By setting AllowAdvertise to “no,” Windows Installer won’t let the feature be installed on demand. For more information about advertisement and installation on demand, see Advertisement.

InstallDefault

An InstallDefault value of “local” means that the feature should be installed on the local computer instead of be run from the network. As there’s no such thing as a “network GAC,” letting the user choose to run the feature from the network makes no sense.

Absent

A value of “disallow” means that the feature is required and must be installed.

Notice the child element ComponentRef. It links the specified component to the feature.

    <!-- Directories -->
    <Directory Id="TARGETDIR"
               Name="SourceDir">
      <Directory Id="ProgramFilesFolder"
                 Name="PFILES">
        <Directory Id="INSTALLDIR"
                   Name="LTWCTRLS"
                   LongName="Litware Controls" >
          <Component Id="LitwareWinControl_Component"
                     Guid="834CE6C7-2532-4428-8582-DA583F73C824">
            <File Id="WinControl.dll"
                  Name="WinCtr.dll"
                  LongName="WinControl.dll"
                  Assembly=".net"
                  KeyPath="yes"
                  Source="..\WinControl\bin\Release\WinControl.dll"
                  DiskId="1" />
          </Component>
        </Directory>
      </Directory>
    </Directory>

This section of code highlights how the WiX schema uses XML hierarchies to represent ownership concepts in Windows Installer:

The Directory element has child Directory elements to indicate subdirectories.

Each component belongs to one directory, and so the Component element is a child of a Directory element.

Files are resources that belong to a component, and so the File element is a child of a Component element.

The root directory of a Windows Installer package must have an ID of TARGETDIR and a name of SourceDir. For more information about the Windows Installer directory structure, see the Windows Installer SDK documentation on the Directory table and Rob Mensching’s blog article series.

Notice that each directory has both Name and LongName attributes. Although every Windows operating system since Windows 95 supports long file names, Windows Installer requires .msi packages to declare short file names by using the 8.3 syntax. If WiX version 3.0 is given a long file name, it automatically generates a stable short file name. In WiX version 2.0, you have to supply both.

Components have both an ID and a GUID. The ID exists mostly to let you provide an ID that has significance to humans who are reading the source code.

This table describes the attributes used in the File element:

Attribute Description

Id

There’s only one WinControl.dll, and so it makes sense to tie the file name and the file ID. Files IDs are global to the .msi package, and so if you install multiple files that have the same name in different directories, you’ll have to differentiate them.

Name and LongName

Files needs both short and long file names, just like directories.

Assembly

Using “.net” tells Windows Installer to install the assembly into the GAC. The assembly is installed only to the GAC, not to the directory specified by the Directory element hierarchy.

KeyPath

A KeyPath value of “yes” indicates that Windows Installer should use the assembly to detect whether the component is installed. (WiX automatically sets KeyPath for you if the file is the only component.)

Source

Where to get the file, relative to the directory where the WiX source code is located.

DiskId

There’s only one Media element in this .msi package, and so “1” is the only choice for DiskId.

Checkpoint

You can test the enhanced installer scaffolding by running the following commands at the command prompt in the <Visual Studio SDK installation path>\VisualStudioIntegration\Samples\Controls\WinForms\Setup\ directory:

Command Description

msbuild setup.proj

Builds the Windows Forms control and installers.

msiexec /i Step2.msi

Installs Step 2. Use gacutil or Windows Explorer in the %windir%\assembly directory to verify the assembly was installed to the GAC.

msiexec /x Step2.msi

Uninstalls the assembly from the GAC.

Step 3: Check for the TCI

The TCI is a VSPackage that handles the registering and unregistering of controls in the Visual Studio Toolbox. The TCI VSPackage must be installed before your installer can install controls. Because you can't count on TCI to be installed on every user's computer, it makes sense to check for it during your installation and then quit if it is not found. This step adds a check for TCI.

<?define ToolboxControlsInstallerPackageGuid = "{2c298b35-07da-45f1-96a3-be55d91c8d7a}" ?>
...
    <!-- Launch conditions -->
    <Condition Message="An administrator must approve or install [ProductName]."> Privileged </Condition>

    <!-- Detect ToolboxControlsInstallerPackage so we can make sure it's installed -->
    <Property Id="TOOLBOXINSTALLER">
      <RegistrySearch Id="TbxPackageKey"
                      Root="HKLM"
                      Key="Software\Microsoft\VisualStudio\8.0\Packages\$(var.ToolboxControlsInstallerPackageGuid)"
                      Type="raw" />
    </Property>
    <Condition Message="The Toolbox Controls Installer Package must be installed before you can install [ProductName]."> TOOLBOXINSTALLER </Condition>

The RegistrySearch WiX element searches the registry and results are compiled into entries in the RegLocator table. The AppSearch standard action processes those entries and sets the value of the TOOLBOXINSTALLER property to the value found in the registry. Notice the use of <?define?> and $(var.) to create and reference a WiX preprocessor variable that holds the GUID of the TCI VSPackage.

Launch conditions must be true for an installation to proceed. In this case, if TCI isn’t installed, the registry search leaves the TOOLBOXINSTALLER property as an empty string. Because empty strings evaluate as false. the launch condition fails, the given message is shown, and the installer quits.

There is no supported way to embed the TCI installer, which is redistributable, in your own installer. You must use a separate executable, for example, a setup.exe, that can install TCI and then run your installer. That’s the only way that Microsoft can address any security or other issues without requiring that you redistribute an updated version.

By the way, TCI is installed with the Visual Studio SDK. Therefore, the launch condition always passes on computers with the Visual Studio SDK installed.

Step 4: Register the Control with the TCI

To register a control with TCI, which is then responsible for registering it with Visual Studio, you must:

  • Write the appropriate registry entries.

  • Merge the TCI custom action merge module.

    <!-- Features -->
    <Feature Id="LitwareCtrls"
             Level="1"
             Title="Litware Controls"
             Description="Litware Controls"
             Display="expand"
             AllowAdvertise="no"
             InstallDefault="local"
             Absent="disallow">
      <ComponentRef Id="LitwareWinControl_Component" />
      <ComponentRef Id="LitwareWinControls_VisualStudioToolbox" />
      <MergeRef Id="TbxCtrlsInstDefaultItemsCA" />
    </Feature>

The new ComponentRef and MergeRef elements associate the registry entries and TCI merge module with the installer’s sole feature. The registry entries and merge module are actually defined later in the file.

    <!-- Directories -->
...
        <Directory Id="INSTALLDIR"
                   Name="LTWCTRLS"
                   LongName="Litware Controls" >
          <Merge Id="TbxCtrlsInstDefaultItemsCA"
                 Language="1033"
                 SourceFile="..\..\..\Redistributables\TbxCtrlsInstDefaultItemsCA.msm"
                 DiskId="1" />

Like components, merge modules are associated with a particular directory. However, because the TCI custom action merge module installs no files, directory choice doesn’t matter.

Notice that the SourceFile attribute in the example points to a directory that relates to the Visual Studio SDK samples. In your own build environment, you may want to define an environment variable that points to Visual Studio SDK redistributables and then use WiX preprocessor syntax $(env.variableName) to refer to it.

          <Component Id="LitwareWinControls_VisualStudioToolbox" Guid="B74650E2-08AF-4748-ABB7-293E6D3A2EDA">
            <!-- Register the control with the Toolbox Controls Installer Package for Visual Studio (Standard edition and higher) -->
            <Registry Root="HKLM"
                      Key="Software\Microsoft\VisualStudio\8.0\ToolboxControlsInstaller\WinControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1631b3e7a8fbcce5, processorArchitecture=MSIL"
                      Value="Litware Controls"
                      Type="string" />
          </Component>

In this bit of code, another component is created to hold the registry entries for TCI. The registry key is always under HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\8.0\. The subkey is the fully-qualified name of the controls’ assembly.

Step 5: Add Optional Support for Visual Studio Express Edition Products

TCI supports the registration of controls in all editions of Visual Studio, including the Express Editions. To control which editions you want to support, you declare your intent to support a specific edition by registering your control in that edition’s registry hive. A detailed list is included later in this tutorial.

If you want to support all Express Editions all the time, you can include all the registry entries in the same component that you use to register support for the other Visual Studio editions. You can also conditionally support Express Editions, so that the user can decide at installation time the editions in which they want your control to be available. Step 5 shows how to conditionally support Express Editions, by using Windows Installer features and WiX’s feature-selection dialog box.

    <!-- Pick up Visual Studio properties from WixVSExtension -->
    <PropertyRef Id="VS2005DEVENV" />
    <PropertyRef Id="VCSHARP2005EXPRESS_IDE" />
    <PropertyRef Id="VB2005EXPRESS_IDE" />
    <PropertyRef Id="VWD2005EXPRESS_IDE" />
    <PropertyRef Id="VC2005EXPRESS_IDE" />
    <PropertyRef Id="VJSHARP2005EXPRESS_IDE" />

WiX includes an extension that has built-in locators for various Visual Studio products and components. The PropertyRef element causes those locators to be linked to the .msi package, and the corresponding properties to be set during the AppSearch standard action.

    <!-- Features -->
    <Feature Id="LitwareCtrls"
             Level="1"
             Title="Litware Controls"
             Description="Litware Controls"
             Display="expand"
             AllowAdvertise="no"
             InstallDefault="local"
             Absent="disallow">
      <ComponentRef Id="LitwareWinControl_Component" />
      
      <Feature Id="VisualStudioStd"
                Level="1"
                Title="Integration for Visual Studio Standard Edition or greater">
        <Condition Level="0"> 
          NOT VS2005DEVENV 
        </Condition>
        <ComponentRef Id="LitwareWinControls_VisualStudioToolbox" />
        <MergeRef Id="TbxCtrlsInstDefaultItemsCA" />
      </Feature>
      
      <Feature Id="VCSExpress"
                Level="1"
                Title="Integration for Visual C# 2005 Express">
        <Condition Level="0"> 
          NOT VCSHARP2005EXPRESS_IDE
        </Condition>
        <ComponentRef Id="LitwareWinControls_VCSExpressToolbox" />
        <MergeRef Id="TbxCtrlsInstDefaultItemsCA" />
      </Feature>
      
      <Feature Id="VBExpress"
                Level="1"
                Title="Integration for Visual Basic 2005 Express">
        <Condition Level="0"> 
          NOT VB2005EXPRESS_IDE
        </Condition>
        <ComponentRef Id="LitwareWinControls_VBExpressToolbox" />
        <MergeRef Id="TbxCtrlsInstDefaultItemsCA" />
      </Feature>

      <Feature Id="VWDExpress"
                Level="1"
                Title="Integration for Visual Web Developer 2005 Express">
        <Condition Level="0"> 
          NOT VWD2005EXPRESS_IDE
        </Condition>
        <ComponentRef Id="LitwareWinControls_VWDExpressToolbox" />
        <MergeRef Id="TbxCtrlsInstDefaultItemsCA" />
      </Feature>

      <Feature Id="VCExpress"
                Level="1"
                Title="Integration for Visual C++ 2005 Express">
        <Condition Level="0"> 
          NOT VC2005EXPRESS_IDE
        </Condition>
        <ComponentRef Id="LitwareWinControls_VCExpressToolbox" />
        <MergeRef Id="TbxCtrlsInstDefaultItemsCA" />
      </Feature>

      <Feature Id="VJSExpress"
                Level="1"
                Title="Integration for Visual J# 2005 Express">
        <Condition Level="0"> 
          NOT VJSHARP2005EXPRESS_IDE
        </Condition>
        <ComponentRef Id="LitwareWinControls_VJSExpressToolbox" />
        <MergeRef Id="TbxCtrlsInstDefaultItemsCA" />
      </Feature>
    </Feature>

To explicitly support each Express Edition, follow this pattern:

  • Create a new feature as a child of the root controls feature. Because the root controls feature has its Display attribute set to expand, all the Express Edition child features will be shown expanded in a feature-selection tree control.

  • Disable the feature by using the Condition element to set its installation level to 0. The condition is a property that is set by one of the locators in the WixVSExtension extension. When the feature is disabled, it is no longer shown in a feature-selection tree control.

  • Associate the feature with the component that contains the registry entries. The components are defined later in the source code.

  • Associate the feature with the TCI custom-action merge module. By adding the MergeRef element only to the features that contain control registration, you make sure that the custom actions are executed only when those features are installed. In a product in which controls are only part of the product, associating the custom-action merge module only to specific features prevents the custom actions from being executed when they’re not needed.

          <Component Id="LitwareWinControls_VCSExpressToolbox"
                     Guid="B74650E2-08AF-4748-ABB7-293E6D3A2EDA">
            <Registry Root="HKLM"
                      Key="Software\Microsoft\VCSExpress\8.0\ToolboxControlsInstaller\WinControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1631b3e7a8fbcce5, processorArchitecture=MSIL"
                      Value="Litware Controls"
                      Type="string" />
          </Component>

          <Component Id="LitwareWinControls_VBExpressToolbox"
                     Guid="B74650E2-08AF-4748-ABB7-293E6D3A2EDA">
            <Registry Root="HKLM"
                      Key="Software\Microsoft\VBExpress\8.0\ToolboxControlsInstaller\WinControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1631b3e7a8fbcce5, processorArchitecture=MSIL"
                      Value="Litware Controls"
                      Type="string" />
          </Component>

          <Component Id="LitwareWinControls_VWDExpressToolbox"
                     Guid="B74650E2-08AF-4748-ABB7-293E6D3A2EDA">
            <Registry Root="HKLM"
                      Key="Software\Microsoft\VWDExpress\8.0\ToolboxControlsInstaller\WinControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1631b3e7a8fbcce5, processorArchitecture=MSIL"
                      Value="Litware Controls"
                      Type="string" />
          </Component>

          <Component Id="LitwareWinControls_VCExpressToolbox"
                     Guid="B74650E2-08AF-4748-ABB7-293E6D3A2EDA">
            <Registry Root="HKLM"
                      Key="Software\Microsoft\VCExpress\8.0\ToolboxControlsInstaller\WinControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1631b3e7a8fbcce5, processorArchitecture=MSIL"
                      Value="Litware Controls"
                      Type="string" />
          </Component>

          <Component Id="LitwareWinControls_VJSExpressToolbox"
                     Guid="B74650E2-08AF-4748-ABB7-293E6D3A2EDA">
            <Registry Root="HKLM"
                      Key="Software\Microsoft\VJSExpress\8.0\ToolboxControlsInstaller\WinControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1631b3e7a8fbcce5, processorArchitecture=MSIL"
                      Value="Litware Controls"
                      Type="string" />
          </Component>

To supporting multiple editions of Visual Studio, just use different registry hives. In Step 4, the Windows Forms control is unconditionally registered under HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\8.0\ to support Visual Studio editions other than Express Editions. The following table lists the registry keys to use for the Express Editions:

Express Edition Registry hive

Visual C# 2005 Express Edition

HKEY_LOCAL_MACHINE\Software\Microsoft\VCSExpress\8.0

Visual Basic 2005 Express Edition

HKEY_LOCAL_MACHINE\Software\Microsoft\VBExpress\8.0

Visual Web Developer 2005 Express Edition

HKEY_LOCAL_MACHINE\Software\Microsoft\VWDExpress\8.0

Visual C++ 2005 Express Edition

HKEY_LOCAL_MACHINE\Software\Microsoft\VCExpress\8.0

Visual J# 2005 Express Edition

HKEY_LOCAL_MACHINE\Software\Microsoft\VJSExpress\8.0

For each edition, there’s a separate component that contains the one registry entry. By using separate components, you can associate the one registry entry with a particular feature. In this way, users can decide at installation time which editions of Visual Studio on their systems should get the control.

    <!-- User interface -->
    <UIRef Id="WixUI_FeatureTree" />

This one final tweak replaces the WixUI_Minimal dialog set with the WixUI_FeatureTree set, which, as the name hints, contains a feature-selection tree control.

Installing a Web Forms Control

In this section, you will create an installer that will install and register a Web Forms control, starting with a copy of the installer from Step 5 of the Windows Forms section, earlier in this tutorial. This installer will do the following:

  • Install the WebControl sample control in the file system by using Codebase.

  • Register the control with TCI for Visual Studio and Visual Studio Express Edition products.

  • Use the TCI custom actions to notify TCI that the Visual Studio Toolbox must be updated with the new control.

Step 1: Install the WebForms Control by Using Codebase

This installer is separate from the Windows Forms control installer but both are similar in structure. The following code highlights the differences between this installer and the one in Step 5 of the Windows Forms installer section. Minor changes, such as changes in GUIDs and feature and component names, aren’t highlighted.

          <Component Id="LitwareWebControl_Component"
                     Guid="F00105C0-1902-47c8-BF29-7B7C2C3D385B">
            <File Id="WebControl.dll"
                  Name="WebCtr.dll"
                  LongName="WebControl.dll"
                  KeyPath="yes"
                  Source="..\WebControl\bin\Release\WebControl.dll"
                  DiskId="1" />
          </Component>

The only difference between the Windows Forms and WebForms controls is that the WebForms control isn’t installed in the GAC. Therefore, the WebForms control lacks an Assembly attribute. (Notice that both Windows Forms and WebForms controls can be installed in the GAC, or as Codebase assemblies in the file system. This tutorial uses both to show how each is handled.)

          <Component Id="LitwareWebControl_VisualStudioToolbox"
                     Guid="B74650E2-08AF-4748-ABB7-293E6D3A2EDA">
            <Registry Root="HKLM"
                      Key="Software\Microsoft\VisualStudio\8.0\ToolboxControlsInstaller\WebControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1631b3e7a8fbcce5, processorArchitecture=MSIL"
                      Value="Litware Controls"
                      Type="string" >
              <Registry Name="Codebase"
                        Value="[#WebControl.dll]"
                        Type="string" />
            </Registry>
          </Component>

Because the WebForms control isn’t in the GAC, it must be registered by using a Codebase registry value so that TCI can locate it. Notice that the Codebase registry value uses a special syntax. Windows Installer processes formatted strings by using embedded [#id] substrings that contain the complete path to a file that has the specified ID.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.