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>
15 comments:
Why not simply use WiX,in stead of gluing bits of it to installshield (very) limited edition projects?
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.
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
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.
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
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?
Yes of course I am OK with that!
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!
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.
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.
hello,
I do not understand how to pass variables from the msi in MM.
Can you help me ?
Hi
Thanks for your post .
I'm a bit beginner with install shield limited edition but because of visual studio 2012 , I must use it.
I need to make a setup kit for my windows service but I need a step by step guide, I wonder if you know any article?
Thanks
Farzad
Post a Comment