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

16 comments:

  1. AnonymousJanuary 19, 2011 at 11:59 PM

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

    ReplyDelete
  2. Christopher PainterJanuary 20, 2011 at 4:09 AM

    IS 2010LE is marketed towards the VDPROJ crossover crowd. With MSFT retiring the tool they need something new.

    LE gives them a similar drag and drop interface for the general case such as files, registry, ini, shortcuts and a bootstrapper with support for many canned prereqs.

    This comes at the expense of limitations such as only 1 feature and many screens that would be available in Professional being shown "adware - locked" style.

    I don't see many of these poeple as making the jump directly to WiX and all that entails. However maybe blog posts like this will fill common needs while providing an initial exposure to what WiX is all about.

    ReplyDelete
  3. JerraJanuary 21, 2011 at 5:48 AM

    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
  4. JerraJanuary 21, 2011 at 5:59 AM

    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
  5. Christopher PainterJanuary 21, 2011 at 8:15 AM

    Here are a few articles to read on the subject. A couple quick notes:

    1) Windows Installer is a Declarative programming model. We increase installer quality and decrease development time by leveraging the capabilties of MSI and focus only on what needs to be done and not how to do it whenever possible.

    2) Merge modules get merged into your MSI. Once built, they no longer exist. It's not installed along with what's in InstallShield, it becomes part of it ; one in the same.

    The Id's need to be globally unique. Merge modules get 'modularized' with the guid of the module so the ID only need be unique to the module.

    Guid's need to be globally unique across the entire world.

    http://msdn.microsoft.com/en-us/library/aa370561(v=VS.85).aspx

    http://wix.sourceforge.net/manual-wix3/generate_guids.htm


    http://robmensching.com/blog/posts/2007/8/10/Zataoca-Classes-of-Custom-Actions

    http://robmensching.com/blog/posts/2007/8/17/Zataoca-Custom-actions-are-generally-an-admission-of-failure

    http://robmensching.com/blog/posts/2007/9/13/Zataoca-Custom-actions-should-be-data-driven

    ReplyDelete
  6. JerraJanuary 22, 2011 at 1:48 AM

    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
  7. Christopher PainterJanuary 22, 2011 at 5:21 AM

    First, I'm SOOO glad that your eyes have opened. Your observations are spot on and I wish everyone got it.

    That said, I heard you say the installation worked on your development machine. I want to impress on you to never, ever test on your own machine. You need a machine you can reimage or even better a virtual machine that you can create snapshots on. Checkout:

    http://blog.deploymentengineering.com/2007/08/hotfix-com-extraction-causes-system.html

    and

    http://blog.deploymentengineering.com/2008/07/virtual-brownbag-installation-testing.html

    ReplyDelete
  8. JerraJanuary 22, 2011 at 8:26 AM

    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
  9. Christopher PainterJanuary 22, 2011 at 9:04 AM

    Hyper-V is only one possibility. You could also use Virtual PC, Virtual Server, ESXi, VirtualBox or others. You could also just buy a cheap computer with two hard drives and store images on the second drive and just keep refreshing the contents of the first drive.

    BTW, I'm thinking about writing a blog and quoting your comments. Are you ok with that?

    ReplyDelete
  10. JerraJanuary 22, 2011 at 9:51 AM

    Yes of course I am OK with that!

    ReplyDelete
  11. RobJuly 2, 2011 at 9:54 AM

    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
  12. Christopher PainterJuly 2, 2011 at 11:35 AM

    When you add a merge module to your InstallShield project, you have to do a Right Click | Properties and then associate the directory in the module with the directory in your InstallShield project. This way MergeRedirectFolder ( or whatever the merge module authoring tool called it ) to the INSTALLDIR in InstallShield.

    ReplyDelete
  13. Nayana & DushyanthAugust 17, 2011 at 11:33 PM

    Your blog is really helpful . Thx ..

    Could you pls tell me if this is possible.
    I have merge module written in Install Shield, Want to call it from Wix installer project. If so, kindly guide me through.
    Thx in advance.

    ReplyDelete
  14. AnonymousOctober 28, 2012 at 2:48 PM

    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. AnonymousOctober 28, 2012 at 7:10 PM

      #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
  15. DuroFebruary 19, 2014 at 2:04 AM

    Hello,

    It would be nice to get answer on this question by Farzad
    http://blog.deploymentengineering.com/2011/01/augmenting-installshield-using-windows_19.html?showComment=1350372167315#c6537629446221854996

    On the other hand, I have another question.
    I also have to migrate my setup projects, and situation is like this:
    We have a project Service Host which can host anything depending on.config file. In current implementation we have 5 different setup projects for 5 different services, which are using same primary output from Service Host and only including their .config file to output.
    1. In IS LE if I add a Service I have to enter installation machine credentials (which I do not know), otherwise installation will fail with 1923 code.
    2. If I check "Installer Class" in properties of primary output, I will end up with 5 services with the name of Service Host. Can I change default name using WiX and how?

    And yes, developers are lazy to read tons of WiX documentation in order to get two lines of xml which can solve their problem.

    All the best!

    ReplyDelete

Subscribe to: Post Comments (Atom)