Wednesday, January 19, 2011

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.

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.

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?

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.

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.

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 automatictransactional/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.

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:

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.

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?

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.

(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.

#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.

It would be nice to get answer on this question by Farzadhttp://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.