Home > Software Deployment > C# DTF and Winforms to replace Internal UI MSI Dialogs Part 1

C# DTF and Winforms to replace Internal UI MSI Dialogs Part 1

We wanted to revamp the UI Sequence of our installer to provide a content rich and dynamic installation experience for end users; something of which MSI dialogs certainly don’t offer.  In this Part 1 post, I’ll go over some of the options I researched and in Part 2 I’ll discuss how I implemented Winforms within the Internal UI Sequence.

To start, I think it’s worth mentioning this is an innovative , ‘first ever’ blog post discussing this method of using C# DTF and Winforms in-line with Windows Installer’s Internal UI Sequence.  I’ve researched this a solid day and similiar posts discussed using an MSI’s dialog button to pop-up a modal Winform, but I’ve not seen any examples of using Winforms in-line with MSI dialogs. /kudos

Windows Installer provides a few alternatives to using the Internal UI.  I’ll mention them along with the drawbacks I noted.

Embedded UI:

  • New feature implemented in Windows Installer 4.5.  (Only included with Windows Vista SP2 and above.)
  • If you want to use it, you’ll have to also deploy the Windows Installer Engine for your target.  I see one for Server 2003, 2008 along with service pack updates in the Redistributable view of Installshield 2011 .
  • Jason Ginchereau writes:

Frankly, I’ve found the embedded UI capabilities of MSI 4.5 very limited, so that in many cases it can’t substitute for a full-featured external UI.

  • Requires us to recreate the SetupProgress dialog.

External UI:

  • A lot of work and time to implement.  Here’s a sample for SetupProgress.
  • Special consideration for Repairs, ARP and admin installs
  • Not possible for Installshield Basic MSI; must use Installscript based project type.
  • Requires it’s own boot strapper to install Prerequisites like the .NET Framework. (i.e. WiX’s Burn)

Alternative Products:

Products that claim to offer rich UI’s.  These would all take considerable effort to re-architect our existing installer.

  • WiX using Burn as a bootstrapper.

Christopher Painter tweets:

The never ending bootstrapper/chainer threads over at the wix-users mailing list. Thank God I’ve had @InstallShield setup prereqs for years.

Internal UI:

  1. Allows us to continue using the Installshield bootstrapper to install prerequisites
  2. Takes the least amount of development time (we don’t have to re-author a SetupProgress dialog)
  3. Works from all entry points: ARP, Admin and Maintenance installs.

Given the above options, I choose to stick with the Internal UI.  As I mentioned at the start, Windows Installer’s  internal UI doesn’t provide the flexibility necessary for rich, dynamic content.  For this reason, I took a look at WiX’s C# DTF combined with Winforms.

In the next post, Part 2, I’ll talk about how I implemented Winforms in the Internal UI Sequence.  Stay tuned!

Advertisements
  1. May 17, 2011 at 3:51 pm

    Sounds like an awesome little project. As I tweeted, I’d be very interested in knowing what kind of “content rich and dynamic installation experience” that you’re trying to provide. It’d be really cool to see a screenshot of what type of UI you’re going for. From my limited research, it seems most users just want something that is quick/easy/intuitive for the install. I can relate to that as I’m installing VS2010 right now and I just click the “Next” button as fast as I can to get through the install. If it’s a long install, I want a % progress bar that I am through it or to know how much longer it’s going to be so I can go do something else.

    Without providing any marketing research, I think users are getting use to the way of the mobile install. One click, maybe one license agree Yes/No button, then a progress bar and BOOM, it’s installed. Similar for uninstall, one click and gone. I think it’d be great to see this kind of intuitive and easy integration into the future of desktop installers. I digress from the topic; self diagnosed A.D.D….leave me alone 🙂

    My 2 cents…
    -jp

    PS: love to see concept screenshots in part II if it’s legal

  2. Anurag
    November 16, 2011 at 5:46 am

    Hi,It looks pretty cool and really interested to know about it.Currently I am facing the similar issue so If possible , Kindly share the concept and idea behind it asap.

    • Nick Skitch
      November 17, 2011 at 6:14 pm

      I’m sorry that I’ve not posted a part II on this subject. I can tell you the way I did it was to modify the UI sequence by deleting some/most of the dialogs provided. In it’s place I put a custom action that called a C# DTF dll that displayed a Winform that was sized to look like the original MSI dialogs. I believe I displayed it ‘synchronously”. The real magic was finding the msi dialog window handle and when you .show your form, you use the window handle as an argument to make your Winform a child of the parent MSI dialog. I then sent a windows message to hide the msi dialog. When my winform was dismissed, the next dialog in the UI Sequence was the progress bar. The handoff from Winform to MSI progress dialog was seemless. I hope that one day I can document this with code samples.

  3. Mano
    September 19, 2013 at 10:59 am

    Hi, can you please document the steps. its really helpful for many people

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: