ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

Wednesday, January 19, 2011

Augmenting InstallShield using Windows Installer XML - Windows Services

In my last blog I explained how you could use a WiX module to extend InstallShield to accomplish installing certificates.  I also mentioned that you could use WiX to inject  Windows Services into InstallShield 2010 Limited Edition even though the tool wasn't designed to support this.

Below is an example of what said WiX source code would look like.   I post this not as some attempt to 'hack' InstallShield LE but more a spirit of  I really don't want to see former VDPROJ developers continuing the horrible practice of writing InstallUtil custom actions to install services.

As an aside, 14 of the 16 lines of XML were authored by IsWiX.  I only had to add the ServiceInstall and ServiceControl elements.  One of these days I'll get around to finishing the Services Designer so IsWiX can do all the authoring.


<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <?define SourceDir="."?>
  <Module Id="WindowsService" Language="1033" Version="1.0.0.0">
    <Package Id="f4e004d1-4fc1-4dab-855d-c46fc2ec3702" Manufacturer="WindowsService" InstallerVersion="200" />
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="MergeRedirectFolder">
        <Component Id="owcB7461B87B05DCA45F57E1CB0917F32A7" Guid="380bbddd-daa7-0744-517b-37da768f5570">
          <File Id="owfB7461B87B05DCA45F57E1CB0917F32A7" Source="$(var.SourceDir)\WindowsService.exe" KeyPath="yes" />
          <ServiceInstall Id="installWS" Name="WindowsService" DisplayName="Windows Service" Description="Windows Service" Start="auto" Type ="ownProcess" ErrorControl ="normal"/>
          <ServiceControl Id="controlWS" Name="WindowsService" Remove="both" Stop ="both" Start="install" Wait ="no"/>
        </Component>
      </Directory>
    </Directory>
  </Module>
</Wix>
Posted by at

9 comments:

  1. Why not simply use WiX,in stead of gluing bits of it to installshield (very) limited edition projects?

    ReplyDelete

  2. I used the XML you posted in a Merge Module project (VS 2010 PRO & Wix 3.5). Modified values to fit my files and folders and it compiled just fine.
    How important are those id's and GUID's? I noticed Component.Id = File.Id but I cannot see in the Wix online Wix schema info on this.
    What do I do with the .msm file?

    ReplyDelete

  3. So this service will be installed and uninstalled in parallell with the program that is installed by the InstallShield?
    Why are custom actions bad? You point it out in several locations but I can't find reasons for them being best left unused.

    ReplyDelete

  4. Absolutely fantastic! I just got the installation to work on my development machine (XP, VS2010 Professional, Wix 3.5, InstallShield 2011 Express).
    I use InstallShield 2011 Express but it should work with InstallShield 2011 LE too right?
    I added the .msm file under "Redistributables" and checked it to be included in the installation. I noticed the service's .exe file showed up under the installation root alongside Setup.exe.
    Initially I got an error that the file path to the .msm file was longer than what the OS supports so I changed the IS2011 CD_ROM build location ("Prepare for Release") to a higher level location to shorten the file path.
    Uninstalled my application and service was removed. :D This is just great! I have read the articles you linked and checked a few more and have still more to read later. A new world is opening itself..
    Ok so I understand now that using custom actions (CA) makes you go outside the "safe"/controlled environment of MSI and any changes to the system will not be included in the automatic
    transactional/rollback sequeces otherwise generated by the installer (if I got it right)? Apparently there are cases where CA's are legit but its best to really look for ways to do things inside within the installer.

    ReplyDelete

  5. Thanks for the advice regarding testing installation packages! Had no idea about that.
    I looked at the Hyper-V video, just as Wix that is something completely new to me. I'll have to look into it. At this stage I have no machine I can test on. I have myself a production 2003 Server on an old HP ML-100 G1 server.

    ReplyDelete

  6. Yes of course I am OK with that!

    ReplyDelete

  7. Hi Mr. Painter,

    Nice post - very helpful! I'm using InstallShield Pro 11 and a VS2010 WiX 3.5 authored Merge Module designed to install a service exactly the way describe in your post.

    Eveything works (serve stats, uninstalled, etc.) except the service and its supporting files are ALWAYS installed to C:\!

    For the life of me I can't figure out why.

    But I am new to the whole WiX Merge Module to extend/compensate for InstallShield.

    Any hints or suggestions would be greatly appreciated!

    ReplyDelete

  8. I tried this on InstallShield LTE that comes with VS 2010. Problems:

    (1) The service isn't installed by the MSM doesn't go into same directory as rest of the installshield installation. This can cause problems if the service requires other DLLs that are installed by the main installer.
    (2) Putting Account="LocalSystem" on the ServiceInstall tag, was necessary for my service.

    Thanks for sharing this approach to extending LTE.

    ReplyDelete
    Replies

    1. #1 above was "operator error" on my part: After adding the MSM generated by WIX to InstallShield LTE to the redistributables, right click on the merge module MSM and choose properties. There you should pick [INSTALLDIR] as the default dir.

      Delete

Subscribe to: Post Comments (Atom)