Installshield To Wix Conversion

1. Installshield To Wix Conversion Chart

I Didn’t Know InstallShield Could Do That?February 28, 2011 FlexeraWithout ranting too much, there are some amazingly useful things that you probably didn’t realize you could do with InstallShield. Either because the capability is not well documented, or because the feature just lies in an area of InstallShield where it’s likely to be overlooked in day-to-day usage. Convert an Existing MSI package into a Project File.File - Open is known to you if you’ve tried to reverse engineer a vendor MSI Package. But did you know that by changing the Drop-Down list for “Open As” from “Auto” to “Wizard” that instead of opening the project, it will let you create a new project file?I’ve used this a few ways in the past. Regaining Project sources, if the original project file was lost. Changing an Uncompressed package into a Compressed package by creating a new release configuration in the new Project file. Converting an MSI built with a different tool to an InstalllShield project (i.e.

Wise, Wix, Orca, InstallAware, etc.)Obviously, there are other possibilities as well. Generally, this works because most records in the project file have a 1:1 mapping with the MSI database, making backwards conversion possible. Opening and Editing Setup.exe FilesNot a documented feature, InstallShield will know how to open many older setups built with an equivalent or previous version of InstallShield.

In more recently built projects, it even has the capability of saving the updated.msi file back into setup.exe!To accomplish this, you have to trick the File - Open Dialog to display all files. Since it’s a standard windows dialog, you just have to type ‘.’ into the FileName field and hit enter.

This then lets you select an.exe file.Note: This will generally only work with a setup that contains an.msi file, and not InstallScript projects. As well, if the package was built with a version of InstallShield newer than what you’re using, this will probably fail and may possibly Crash InstallShield.

Creating a Merge Module out of an MSI PackageBuilding off of the entry on ‘Wizard’ Mode, once you’ve gotten a setup into an InstallShield.ism format, the ‘Export Components Wizard’ is available under the ‘Project’ menu. You can export to an existing project file, or export as a new Merge Module Project. XML System SearchesNeed a value from an XML File?

Put down that Script! While not natively supported by Windows Installer, InstallShield has quietly supported this functionality for years via a C.dll custom action. Simply view the Help to find more details. Use Property References All Over the PlaceIf you find yourself saying, “Boy, I wish X feature could use a Property reference”, there’s a sort of process you can go through to figure out if this is a possibility:1. Check to see where the Table data is stored.

Basically, type a descriptive string into the UI you are using to configure whatever data, and search for it in InstallShield’s Direct Editor.2. Once you’ve found the table record that holds your data entered in step 1, press ‘F1’ to bring up the Table Reference.3.

If the field has a data type of ‘Formatted’, then it can use a Property Reference. There are some other field types that also support this formatting:TemplatePathRegPathAnyPathFormattedSDDLTextShortcutInstallShield-Specific tables (Generally named like ISxxx) is a separate topic, however. Since these tables are used internally are not intended to be manipulated directly, there’s no table reference for them.However, while not advertised in all parts of the Product, generally the InstallShield Developers will use the Windows Installer API “MsiFormatRecord” when processing a data table in an.msi package:MsiFormatRecord FunctionIf a data table contains a string value of some sort that’s not obviously used as a Primary key, there’s a decent chance it will be formatted by the associated InstallShield Custom Action at runtime before the data is used. My recommendation is to try a property reference if you’re not certain, and see if this works for you.

InstallShield MSI ToolsWhen you’ve got an MSI that doesn’t work quite right, what do you do? That’s what these were designed for. The InstallShield Help contains on these, but I’ll list what I find to be most useful:MSIDiff.exe – Allows a Visual Diff of two MSI databases. Incredibly useful when some new revision breaks, and you are not certain why. Or in the case you are trying to diagnose a tough Patching issue where the state of the database tables becomes very relevant.MsiSleuth.exe – Allows you to see the various Product, Feature and Component states for MSI packages. This I found to be useful when Virtualizing MS Office, since Microsoft Office uses Windows Installer API’s to determine whether it should manually trigger a repair or not.

In this case, I added this tool to the sequenced App-V package.RegSpyUI.exe – Not officially an “InstallShield MSI Tool”, this tool is a standard part of InstallShield, and gets placed here:C:Program FilesInstallShield2010SupportRegSpyUI.exeThis little tool lets you take control of extracting COM Information from a particular file. In the case of.exe files, it simply runs the.exe file with the /RegServer parameter. If your application doesn’t specifically handle this parameter, this will also capture other registry configuration that occurs before the application exits. Making Order from ChaosSometimes it becomes necessary for records to be processed in a particular order. However, Windows Installer is not designed with this in mind, since like-operations are done at once instead of installing discrete units of files and registry data piece by piece.One common scenario is the need to register.dll files in a particular order, due to dependencies between the modules. Which, as we can see, the SelfReg table contains no ‘Order’ column with which to accomplish this:Luckily in this case, the InstallShield style of self-registration (a setting under Tools - Options - Preferences) uses the ISSelfReg table which contains an Order column:But what if the table didn’t have an ‘Order’ column? In the absence of a field that specifies the order in which records are to be processed, there are a couple of things that can be done to mitigate the issue of ordering.Windows Installer, being just a database that gets processed by a Windows service (msiexec.exe), typically processes records in the order in which they are returned from the database.

The order it uses for this is based on the order in which the records were entered into the database, so there is 2 methods of implementing the order here:. Changing the Project File format from Binary to XML. This stores records in a human-readable format that you can specify a particular order, which determines how InstallShield ends up inserting the records into the table while building the project.

Cutting and pasting the records in question until they end up in the correct order. In some views of InstallShield, such as the XML File Changes view, records are displayed in the same order that they will be processed later, so if you’ve implemented it correct, it will be visible here.

It's been no secret that I've favored InstallShield over WiX for many years. I've used InstallShield products since 1997 and I've shipped hundreds of installers using this versatile tool. InstallScript, XML Locator, Setup Prerequisites, Multiple Instance Support, COM Extraction, MySQL, Dialog/Control editors, Product/Release configurations and Component authoring wizards/views have made me a very productive and profitable person over the years.Unfortunatly, there are also things I dislike about InstallShield. The DRM activation ( and now reactivation with IS2010 ) is horrible, difficulty in trying to get updates in an offline scenario (which we always are for security purposes), the random crashes, the horrible DTD/XML transformation, sequenced primary keys and of course, the removal of the stand alone build from Professional and totally useless collaboration tool combined with the really high price of the product.If I'm hurting anyones feelings, I'm sorry. It's hard for me too since I've used this tool for so long and I do believe it's still a very good tool for many development shops. Just not for mine.At my day job, I lead a team of 4 ( going on 6!

) setup developers. We collectively maintain dozens of installs that generate and consume hundreds of merge modules from a software product line. Our typical installer ships 10,000 - 15,000 files and includes countless databases, services, webservices and many chained packages of programs that we integrate with. All of this occurs on many active branches.Unfortunatly InstallShield with it's DTD XML and incremented primary keys just doesn't work well in this environment. Merging branches back together in clearcase is a nightmare since you always end up with unresolved conflicts. The XSD XML is 95% smaller then DTD XML and is way more expressive.

Also thanks to deterministically unique primary keys and guids, changes done on multiple branches can actually merge back together easily.The problem with WiX of course is the lack of gui designer abstractions and visualizations. Fortunatly I finally have a solution for that.

Installshield To Wix Conversion Chart

I've recently had an internal tools developer assigned to me to come up with our own collaboration tools to sit on top of votive. Once complete we are hoping to once again try decentralized setup development. I'm not sure it'll work ( it didn't last time ) but we are going to give it a try again. The reality is our environment is growing so fast that we need to retool and try new strategies to keep up. Hiring more and more people just doesn't seem to work anymore.

I saw Stefan's side-by-side InstallShield license comparison of IS 2009 and IS 2010 licenses (see and am concerned about the activation stuff as well.We use IS 2009 Premier for development (2 licenses) and the Standalone Build on numerous build machines (VMWare VMs all configured the exact same way).If Acresso is going to discontinue the Standalone Build and require a separate license for each build machine then you better believe we'll be switching to WiX pretty darn soon! Chris,We have had the same thoughts about InstallShield for the past two years. However, each year the thing that keeps us going is that we lack the manpower and funding to push us into something new.This past year we reconfigured the DIM processing system for our own use. We now use system to populate the ISM by running a macro. This allows us to take care of many of the problems that InstallShield had with their implementation of the DIM processing system at build time.One day the proverbial final straw will break the camel's back and we will move to another tool - probably WIX too. It's actually taken me about 5 years to warm up to WiX and while I haven't completely switched over, I am now at a point where I am slowely moving my entire code base (at work) over to it.

My reasons involve DRM, cost and a project format that is lousy for branching and merging. When I look at my companies needs, these three things are critical to be solved and we've decided to do so.But for a great many people, I still think InstallShield is a fine product as most people will probably not be troubled by these issues as much as we are. Technically you can edit your built installshield msi and extract the DLL from the binary table. Then take a look at the CustomAction table and you'll see your CA's call into the DLL using a series of function entrypoints named f1, f2, f3.That's enough information to call those custom actions using WiX but if you ever want to make code changes you'll have to rebuild the InstallShield project and reextract the DLL.So for all practical purposes, you'll have to refactor those InstallScript Custom Actions. C if you don't have a dependency on the.NET framework and C#/DTF ( way easier ) if you do have a dependency on the.NET framework. I am an Architect with expertise in Application Life Cycle Management.

Specifically, Microsoft TFS, C#, Windows Installer (MSI), InstallShield and WiX technologies. Additionally I am the author of the ISWIX Blog and the Industrial Strength Windows Installer XML (IsWiX) project on CodePlex.Additionally, I have strong skills in Build Automation ( NAnt, MSBuild, TFS, BuildForge ),.NET/C# Development, Network Administration. Systems Administration and Systems Engineering.Chances are if you can name it, I've done it for many organizations including:United States Marine Corps,Electronic Data Sytems,Continental Airlines,The Home Depot,Textron Systems ( Overwatch Systems ),Robbins-Gioia,McAdams Technologies,Triangle Technology,Hart InterCivic,Manatron,MultiMedia Games,NoMoreForms,RicherDevelopment,VistaSG,SouceSentry,SANtools,OnnX,KelRad Software,Liveware Publishing,ReHab Documentation,Macheen,IJJC,RatchetSoft,RiskServers SAand many other clients who prefer to remain annonymous.Please feel free to check out my.