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

Friday, April 8, 2011

Lack of IIS Support in IS Automation Interface

In a previous blog entry I talked about how a couple of InstallScript UAC bugs went uncorrected for several years.  "Anonymous" left a comment saying "it wasn't a big deal".

So today I'd like to leave a little bread crumb for something that IS a really BIG deal.

InstallShield markets itself as having an Automation Interface and not just a big fat IDE.  That is correct and I make extensive use of it in my blending WiX with InstallShield designs.

InstallShield markets itself as having Native IIS 7 support.  That is correct and it's one of the big reasons I continue to use InstallShield.  WiX 3.5 is supposed to be up to that level but for now I've stuck with IS.

However, recently I discovered that InstallShield's automation interface has 0% coverage of the IIS functionality.  That is a huge omission as IIS changes represents a major component of the InstallShield tool.  

Now I wasn't in any of the meetings but it doesn't take a rocket scientist to figure out what probably happened.     Marketing and Engineering probably realized the need for a revamped IIS subsystem to deal with the latest versions of Windows / IIS.   They probably scoped it out and somewhere along the lines decided to drop automation support from the roadmap so they could keep their ship date and announce a new feature.

So there you go, sure they have automation and sure they have IIS but they don't have automation for IIS which in my book means they don't really have automation.  It simply is not feature complete.   This isn't the first, second or third time I noticed glaring holes in the automation interface but it's the most significant IMO.  I can kind of ( not really ) understand a property here or there missing but for an entirely new/rewritten feature to be omitted tells me that the automation interface isn't really a priority and that it's a false feature.   That it's only there for marketing purposes so that InstallTalk can blog it's usefulness.

Sure, I can "hack" around this problem as has been suggested to me  but I don't considering saving and closing the project object  then hitting it with a DTF SQL Query or  XML DOM to be "automation".  This is raw data layer access.

No doubt some at InstallShield will read this and say "he's spot on" and some will read this and say "oh Chris is off his rocker again... this is really no big deal.". 

So let's see how many years it takes for InstallShield to fix this one. 

Wednesday, April 6, 2011

Interesting Thoughts for Today

I just came across two interesting blog posts today that I thought I would share.  The first is from The Agile Warrior:

Wherever you are working, pretend you are going to be there for ever.


This is especially important if you are a contractor.


When you act like you are going to be somewhere forever (and that it’s YOU who is going to be maintaining this software) you behave differently.

You start to write more tests.
You don’t mind creating the occasional support document.
You clean up as you go.
And you are less likely to sweep things under the rug.
You are nicer to people (you are going to be here forever after all).
And you start to care.

Making this attitude a habit isn’t just good for the soul. It’s good for the bottom line.
Contractors who don’t care don’t get asked back.
And nowhere is the world more small than your local IT community.

So start caring. Pretend you are going to be there forever and you’ll naturally act accordingly.
The second is from Joe Homs

What works equally well is to pretend you are leaving tomorrow. It’s a great exercise if you really do think you’ll be at your company for a long time and will have to maintain the software you create. If you’re leaving tomorrow, what would you fix, document, clean up, or write tests for? Who would you be nice to? We used to call this the “Hit by a bus” effect, but some people liked to use “the lottery winner” effect as the name. It really helped people get that they had to maintain their systems better and not become bottlenecks and share information.

Joe then goes on to quote Carl Gustav Jacob Jacobi  with:

“Invert, always invert.”  - Carl Gustav Jacob Jacobi 
Continuing, Joe says:

If you haven’t heard of Jacobi, you should check him out. Anyway, basically, all you have to do is think of the opposite of whatever position you are in. Have lots of time? Now pretend you have little. Have lots of people? What if you only had a few? Have only a little money? What if you had a lot? Stretching the constraints in your projects can really help you see new solutions. It’s helped me solve problems countless times for myself and my clients.


Fascinating thoughts if you ask me.

Monday, April 4, 2011

InstallShield Bug Backlog

I was reading through the InstallShield 2011 release notes from August 2010 when I noticed the following:

InstallScript Functions ServiceExistsService and ServiceGetServiceState No Longer Require Elevated Privileges

The InstallScript functions ServiceExistsService and ServiceGetServiceState no longer require elevated privileges. Therefore, installations can now call these functions when end users have limited privileges, such as in the Install UI sequence of a Basic MSI installation. This enhancement resolves issue IOC-000059857.

I then remebered blogging about that problem back in May of 2007. ( See: Vista UAC implications of ServiceControlManager API calls )

As I recall, this fix couldn't have been more then one or two lines of code.  Basically you just had to open the SCM API requesting less privs when you were only checking the status of a service.  I remember this because I had posted a workaround on the forums myself.

This bug was found in IS12. 

Was it fixed in IS2008?  Nope.
Was it fixed in IS2009?  Nope.
Was it fixed in IS2010?  Nope.

It was finally fixed in IS2011 which was released in August of 2010.  That's 39 months to fix a simple defect.  Surely all of those maintenance dollars from support contracts could have sped that up a tad.  Instead InstallShield continues to live up to their reputation of shipping new features but not fixing existing issues.

I'm going to be keeping that fact in my mind when I think about how long it takes WiX to ship a new release and how InstallShield now loves to throw the "Agile" word around in their marketing.

Monday, March 14, 2011

Guess What Else InstallShield Can Do!

Flexera's InstallTalk blog recently posted a blog articled titled `I Didn't Know InstallShield Could Do That?` I mainly reference the article not for the content but to use it as a hook for a more interesting albeit darker version:

InstallShield can be used a bootstrapper for a WiX MSI.

...evil laugh...

It's simple.  InstallShield 2011 Premiere has some new features that allow you to inject custom commands at various stages of the build process.  One of these steps is the Precompression Event.  This event occurs right after the MSI has been built but not yet digitally signed.   This allows you to do custom post build processing of the MSI without breaking it's digital signature. 

InstallShield's handling of Setup Prerequisites ( the kind that run before you MSI ) it's fairly loosely coupled from the MSI.  Feature prerequisites are a bit more complicated but not impossible to reproduce.   Let's look at the work flow.

1) Create a Basic MSI project ( call it anything you want ) and then give it a feature and a component.

2) Add the .NET 3.5 SP1 setup prerequisite using the redistributables view.   Right click and select properties and type in a release flag of DOTNETFRAME35SP1.

3) Create use the Release Wizard to generate a new Product Configuration and Release.  Pick a compressed network image with setup.exe.

4) Set ProductName, ProductVersion, PackageCode, ProductCode and UpgradeCode to the same values as in your WiX msi.  Set the Generate Package Code value to false and set the MSI Package File Name field to be the same as your WiX msi ( without the .msi part ).

5) Copy your WiX MSI to the location specified as under Path Variables.

6) On the Build Events tab of the release paste in the following precompression command

cmd /c copy "<ISPROJECTDIR>\WiX35.msi" "<ISPROJECTDIR>\WiX35\Release 1\DiskImages\DISK1"

Saturday, March 12, 2011

Redemption of Visual Studio Deployment Projects

For years I've spoken of the horrors of Visual Studio Deployment Projects:

  • Every file and every registry key is always a key file of it's own component
  • ShortCuts are always advertised
  • Dependency Scanning is next to impossible to disable
  • Custom Action support is horrible  ( deferred only )
  • No support for MSI concepts such as ServiceInstall encourages Custom Action anti-patterns
  • Many more ( Rob Mesnching has an blog post out there somewhere with 100 comments of people's compaints about VDPROJ and support of Windows Installer XML.
The loathing of VDPROJ was so great that Microsoft is replacing it with InstallShield 2010 Limited Edition.  Now I'm going to say something that shook my world view to it's foundation:

-gulp-

Visual Studio Deployment projects, used in a very specific way, is....

-gulp-

pretty useful.

-exhale-

Wow, there, I said it.   Go ahead, get your laughs of disbelieve out.   I know, I know, Chris has finally fallen off of his rocker.   OK, you ready for my defense?  Here goes:

I came to realize with  my 'all component data goes in merge modules' using IsWiX and WiX that essentially every single complaint that I had about VDPROJ stemmed from how it authored component data and exposed custom actions.    By abstracting all of this into WiX merge modules and leaving next to nothing in the VDPROJ installer project  I am able to build an installer that passes ICE validation and presents no garbage that causes concern for me.

 Sure, it's a fairly limited solution but for a great many projects it's probably actually is good enough.   I get a UI that can be somewhat customized without diving too deep into the details, a bootstrapper that can handle basic prereqs like .NET 3.5/4.0, SQL Compact, C++ runtimes,  the ability to define System Searches and Launch Conditions and support for Major Upgrades.

As long as I use a discriminating eye and void using VDPROJ to do anything else like define files and folders, shortcuts, registry and so on, it's really no that bad.

Instead I use the merge module for everything.   Need to author 1,000 files?  No problem, just drag and drop in IsWiX and it's done.    Need to give a few of those files shortcuts in the start menu?   No problem, write a few Directory, ShortCut and Icon elements and that's done.   Need a Windows Service?  No problem, ServiceInstall and ServiceControl elements.   Create a Service Account?  Configure the Firewall?  Find the Visual Studio ItemsTemplates directory?  Check, Check, Check.

Sure, I'm going to be limited to one feature ( which makes variation points difficult and resiliency repairs intensive ) and I won't be able to do quiet a bit of customization but some people probably don't really need this anyways.

It's like going to one of those 120+ item buffets at the beach when you are on vacation.  If you ignore those 100+ items that junk and stick to the 10-20 items that are good and then bring a few of your favorite adult beverages from home, you'll probably have a pretty good time on the cheap.    I know, bad analogy but I hope it gets the point across.

So there you have it.  A somewhat cautious yet positive endorsement for the use of VDPROJ.  Who would have thought it?

Thursday, March 10, 2011

Installation Collaboration Workflows using Free Tools

Recently I was asked to explain the workflow for Industrial Strenth Windows Installer XML (IsWiX).  In a nutshell IsWiX is all about enabling collaboration by enlisting the help of various contributors in defining the contents of the installer.  This is done through the use of Microsoft Merge Modules.   We use MSM's rather then fragments and libraries because the intent is to interop with other tools such as InstallShield 2011.

At my day job,  Visual Studio is included in the standard developer image which pretty much everyone in Engineering gets.  Recently I was doing some work for a client when it became clear that the person who could best contribute to the project wasn't a developer and didn't have Visual Studio.    While VS is not strictly required by IsWiX it really does help.   So I started looking for a solution to the problem of a non-developer persona contributing to Setup and I came across the following:

Microsoft offers a free, redistributable download: Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package ( Installs .NET 4.0 )

 This installer basically gives you a stripped down Visual Studio IDE with most tools and languages missing.  It just happens that Windows Installer XML 3.5 supports this shell.  ( As an aside, WiX 3.0 supports the 2008 version of the shell. )  Finally, IsWiX (Requires .NET 3.5 SP1) also supports this shell.   So after downloading these three/four packages on an XP SP3 image we suddenly have a fully functioning IDE for authoring merge modules.

Now let's go through the workflow.

1) Start Visual Studio 2010
2) Select  File | New Project


3) Select Merge Module Project and pick a location and project name followed by OK. 

4) After the project is created and shown in solution explorer, rename the MergeModule.wxs to the "[project].wxs". (It'll work if you don't know this but it really gets annoying having dozens of wxs files with the same name. 

5) Remove the TODO Create Component comments and save the WXS file.


At this point we are really just doing standard WiX stuff. Now let's go play with IsWiX.


6)  Select Tools | IsWiXAddIn ( The one with the cheesy looking smiley face. )



The first screen to come up in IsWiX is the General Information designer.  This is where we can view and edit information related to the ModuleSignature and ModuleDependency tables. ( Wix, Package and Dependency elements in WiX speak. )

7) Click on the Files and Folders Designer


The files and folders designer is where you can define the say which source files get installed where.  In WiX this will be your Directory, Component and File Elements.   If you look closely you'll see it's only letting you pick files from where the wixproj and wxs files are.  This is because by default the designer orientates itself to the current directory.  Let's change it to C:\

8) Click on the Code View Tab


Notice that IsWiX has authored a special preprocessor variable called SourceDir and assigned it a value of '.'.   Let's change that line to read  .... SourceDir="..\..\.." ( the number of ..'s will depend on where you put your wxs file or you can just point it to some other directory if you'd like. )  Now let's go watch the effect:

9) Click on the Designer View tab


Note the source files view now points to C:\.   Let's author some files and folders into our merge module.

10)  Drag a folder from the Source Files directory tree to the MergeRedirectFolder node on the destination folders tree.


Now we can see the directories / subdirectories and files shown in the destination.  Let's send these changes back to visual studio.

11)  Click the save button and close IsWiX.



At this point Visual Studio will notice that the contents of our wxs file has changed and ask if you want to reload it.

12) Click Yes


From here we can see the XML that IsWiX authored for us.  We can now rebuild the project to verify that the module builds.

13) Right click the merge module project in the solution view and select Rebuild.

By now it should be obvious that IsWiX can allow non-developers to author merge modules.  But WiX developers can also edit the raw XML by hand and add in additional elements such as ServiceInstall, ServiceControl, ShortCut,  ProgId and so on.   Most edits by hand will have no effect on IsWiX.  Eventually it's hoped to write additional designers that can automate all of these elements.

The other point I'd like to make is the workflow that I use this with

1) Meet with subject area experts ( Dev, Web, Docs, DBAs et al ) and have a dialog where we provide them a basic understanding of Installers and they provide us a basic understanding of the design of their solutions.

2) Come to an agreement on how their solution breaks down into Feature and Merge Modules.   Implement the feature tree in the installation tool of your choice ( InstallShield 2011 for me )  and do the initial setup of the merge module solution.

3) Inform the developers that it's now their job to keep the modules up to date and that we are available to assist / answer question and do additional meta markup such as services and COM.

So there it is in a nutshell.  How I do collaboration using IsWiX / WiX and InstallShield.   If your needs are limited you could use WiX or InstallShield 2010 Limited Edition and have a complete system with nothing but free tools.

Any questions?

PS-  Just for fun I decided to try to install InstallShield 2010LE on the Visual Studio 2010 Shell.  It kind of worked.   It did install and I could open an existing ISL project but the ability to create a new LE project from the File menu was missing.   This isn't important to the Collaboration discussion I mentioned above because I would expect the Setup developer supporting all of this would either have WiX, InstallShield Profesional or Visual Studio and InstallShield LE.



Sunday, March 6, 2011

.NET Reflector is Priceless

Recently, thanks to the Big Swinging Developer, I was given a license of .NET Reflector.

I just wanted to say that Reflector really is priceless!

Just today I was working on a new install for a remote customer and wouldn't you know it, the application threw a null object reference exception when I tried to start it!

I didn't have any sources or symbols so I could have thrown in the towel right there.

Instead I used Reflector to export the assembly to a CSPROJ and rebuilt it so I could have my own symbols and source code. Before I could say "Big Swinging (Install) Developer" I was stepping through the code and found the source of the problem.

So instead of having the usual "works on my machine"discussion that so often accompanys integration I had the remote developer fixing the problem.

Priceless!  Thanks redgate, Red-Gate or Red Gate. ( Not sure how it should be spelled! )