IsWiX4.0.15247.1 Released

In the past few weeks I’ve completely revamped my development and build environments to adopt the latest versions of Windows, Visual Studio and Windows Installer XML.  In the process I decided that it was time to look at WiX Toolset v4.0 (beta) and the implications on Industrial Strength Windows Installer XML.

I had read tidbits about WiX v4.0 being a redesign with tons of breaking changes.  I had also read that WiX v3.x would have many more releases.   My concern was that eventually v4.0 would be complete and it would result in IsWiX become end of life.

My findings at this point are:

  • WiX v3.x and v4.x mostly install side by side.   You end up getting two sets of the compiler and MSBuild targets files which means that you can have wix v3 and v4 projects in the same solution and they will both build.
  • WiX does not install Votive side by side.  Last one on (or repaired) currently ‘wins’.  For the most part this isn’t completely horrible since Votive hasn’t really changed much.
  • WiX will only show you project templates for the version of Votive that is active.  So if you want to create a v4 project you might have to repair WiX v4 and if you want to create a v3 project you might have to repair v3.   Read on for how IsWiX is a little different and doesn’t have this problem.
  • WiX v3 and v4 have completely different XML and C# (DTF) namespaces along with different Import statements in their .wixproj files.  Presumably WiXCop or some other tool will help with migrations but at this point it’s all done by hand.
  • WiX v4 is currently beta and buggy.  Attempts to use WiXUI and Merge/MergeRef resulted in light errors. 

Ok, so with that as our current platform, here’s what I’ve done with IsWiX

  • IsWiX has a series of project templates that get zip’d as part of the build process then laid down and registered with Visual Studio during the install.  I split them into two sets: v3 and v4. 
  • The project templates screen is starting to get a little crowded so I organized the installer to have v3 and v4 project template features.  They default to install if the WiX v3 / v4  MSBuild targets are found.  This way people who don’t yet have WiX v4 don’t have to be bothered by the new templates.
  • I had a lot of hardcoded namespace references in IsWiX.  This has all been refactored so that IsWiX looks at the in memory document and uses the v3 or v4 namespace as appropriate.
  • The namespaces designer view now offers the correct sets of namespaces based on the above root namespace behavior.
  • The XML editor designer view also has the same behavior for proper validation / intellisense processing.
  • I tested all of the designers but there is a chance that one of my refactoring’s, well, sucked.  I’m sorry, I don’t have unit tests to know for sure.  If you find a bug, please report it and revert to IsWiX 3.0.  I will follow up with an IsWiX 4.0 fix in a matter of days possibly hours.

So, I think that’s about it. Head on over to CodePlex to download the new release!  Here’s a few pictures to illustrate the above points:


DTF Bug with new Windows 10 Apps and Features

One of my customers came across an uninstall issue on Windows 10 and shot me an email.  It seems Windows 10 has a new way of adding and removing software:

The problem was users were calling into my customers helpdesk reporting the uninstall being blocked by a custom action. The common theme was that uninstall from the legacy Programs and Features worked but that it failed from the new Apps and Features.  My customer provided me log files and the following stood out:

Action start 11:22:33: REDACTED.
SFXCA: Failed to create new CA process via RUNDLL32. Error code: 575
CustomAction REDACTED returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

This indicated a WiX DTF SfxCA error.  575 means that RunDLL32 failed to initialize. 

In my good log I saw:

Action start 11:36:35: REDACTED.
SFXCA: Extracting custom action to temporary directory: C:UsersREDACTEDAppDataLocalTempMSIAFD1.tmp-
SFXCA: Binding to CLR version v4.0.30319
Calling custom action REDACTED!REDACTED.CustomActions.REDACTED
MSI (s) (30:20) [11:36:36:464]: Doing action: REDACTED
Action ended 11:36:36: REDACTED. Return value 1.

That’s what I expected to see.  Ok, so what’s different?  Again I looked at the logs.

=== Verbose logging started: 10/17/2015  11:36:34  Build type: SHIP UNICODE 5.00.10011.00  Calling process: C:WindowsExplorer.EXE ===
MSI (s) (30:20) [11:36:34:401]: Command Line: REMOVE=ALL CURRENTDIRECTORY=C:Windowssystem32 CLIENTUILEVEL=2 CLIENTPROCESSID=2704

and from the bad:

=== Verbose logging started: 10/17/2015  11:22:31  Build type: SHIP UNICODE 5.00.10011.00  Calling process: C:WindowsImmersiveControlPanelSystemSettings.exe ===
MSI (s) (1C:F0) [11:22:31:794]: Command Line: REMOVE=ALL CURRENTDIRECTORY=C:WindowsImmersiveControlPanel CLIENTUILEVEL=2 CLIENTPROCESSID=3420

My customer was using WiX 3.7. I decided to set out to reproduce the problem with 3.7 and 3.10.  My first attempt failed as I scheduled the custom action for deferred and it worked.  However when I changed it to immediate execution, I was able to reproduce the problem.   That’s very strong evidence o me that this new “immersive control panel” process has an environment that is impacting DTF’s ability to find and launch RunDLL.

Hopefully this write up will help the WiX guys find a resolution.  You can find the bug logged here.


 Further testing indicates this is limited to 64 bit Windows 10.  32 bit seems to function normally.

I did a simple Type 2 EXE custom action test and it called RunDLL32 just fine.

<SetProperty Id=RunDLL Value=rundll32.exe After=AppSearch />
  <CustomAction Id=test Property=RunDLL ExeCommand=printui.dll,PrintUIEntry /? />
  <Custom Action=test After=InstallInitialize>REMOVE=”ALL”</Custom>

Building and Deploying a Windows Desktop Application using IsWiX

I posted a quick, low budget (silent) video on YouTube demonstrating how to create a basic windows desktop application using Visual Studio / C# / WPF, package it using WiX / IsWiX and finally test the install and uninstall.  The entire process is two minutes.

The flow goes like this:

Step 1: Create the application and stage it for the installer to consume:

1) Create a WPF project somewhere on your harddrive.  Name the solution Application.
2) Place the following postbuild command in the project:

  xcopy /iery “$(TargetDir)*.*” “$(SolutionDir)..InstallerDeploy”

3) Build the project and close the solution.

Step 2: Create the installer
4) Create an IsWiX installer in the same directory as selected above. Name the solution Installer.
5) Open the merge module wxs fragment and select the IsWiX addin from the tools menu.
6) Use the Files and Folders designer to author your files into the merge module.
7) Use the Shortcuts designer to create a shortcut on the desktop.
8) Exit the IsWiX addin.
10) Build the MSI

That’s it!  The source tree is 100% compatible with Microsoft Team Foundation Server so checking it all into TFS and creating a build for it is a piece of cake.

IsWiX 5th Anniversary Release 3.0.15106.1

IsWiX is coming up on 5 years old. Wow!  Where did the time go?

It has been such an interesting journey.  The year was 1996 and I was fresh out of the Marine Corps traveling the world as a DoD contractor.  Over the next year I experienced the pain caused by poor deployment planning and crappy installers.  I married my wife Cheryl in 1997 and a decision was made to stop traveling 100K miles a year.  I used my lessons learned in the field experience to get a transfer and suddenly found myself in a meeting where an architect was talking about how great InstallShield Install From The Web was and how we were going to create “Client Software Distribution” aka “CSD”.   Everyone then looked at me.  I nervously asked “So who’s the expert on this?” to which the reply was “you are”.


It’s been a whirl wind ever since.  The story picks up again in 2005 when I moved to Austin, TX.  I was a pretty good setup developer by then but it was here that I was introduced to the demanding challengers of Product Line Development.  I did my best but in the end I was completely hampered by the choice someone had made to embrace agile setup development despite the fact that no suitable tools existed yet.  They decided to use Visual Studio Deployment Project merge modules since all the developer had Visual Studio and no one wanted to do WiX XML by hand or pay for licenses of InstallShield for all the developers.  In the end it was a complete disaster and I left the company.

But I learned a lot from that job and I kept finding myself coming back to merge modules and using InstallShield product configurations to be more efficient.  I kept looking for ways to embrace agile setup development in ways that didn’t make my life hell and the installer crappy.

I always resisted creating my own tools.  It’s probably because I came up through the ranks in a company that believed in integrating off the shelf software instead of reinventing the wheel.  I wasn’t some fresh out working for a big name silicon valley company with something to prove. I just wanted to get the job done quick, cheap and bulletproof.  However, as time passed, I came to realize that the installation tools market was mature and that I couldn’t count on the innovation I needed to come to be.  It was at this time I remembered what my old boss (Col Truman Crawford) in the Marine Corps would say:  “If it’s to be, it’s up to me.”

So in June 2008 I posted Maybe I Should Roll My Own. It was just a casual exploration but I think it really did get me to start thinking about it.  Later in Nov 2008 I returned to the company that I had previously tried and failed to succeed at.   The barriers that had caused my failure had been removed and I now had complete authority to make all architectural decisions.  The installers group had swung away from agile back to a centralized model and with it had come a whole bunch of problems.

To be honest, I don’t really remember any of these conversations but I imagine we had them. My friend Chris Tyler was really good about forcing us to write down our roadmap items and somewhere in there the vision was born:  We would write our own internal “WiXShield” program that would enable us to embrace agile setup development *AND* achieve the highest quality standards we could set for the organization. From the very beginning we knew we would want to release it as open source.

So I was loaned 3 part time developers for 3 months and WiXShield was born.  To be honest I don’t remember when that was exactly.  We trained all the developers on how to use it and we went across every software baseline that we had solution by solution and redid everything in WiX. It was amazingly successful.

At some point we realized that the company simply wasn’t going to be able to publish WiXShield as open source due to the sensitive nature of our work.  To this day I don’t know who pulled a miracle or what they threatened (probably that I would leave the company if it didn’t get published) but some how  Textron Systems and I came to agreement that all intellectual property rights would be assigned to me with the stipulation that I would initially publish it as an open source project.

I remember coming home with CM issued CD-ROM of all the sources.  This was truly amazing as you simply didn’t take software in or out of that building!  I had a celebration dinner with my family and then stayed up late rebranding everything to IsWiX and checking it all into CodePlex.

My eyes were bleary from the all-nighter that I pulled when I posted our first release on CodePlex.  Then Cheryl, in remission from cancer, and I took off for a week Jamaica to spend quality time together.

So why “IsWiX” with a red and blue logo?  Well, officially it stands for Industrial Strength Windows Installer XML and IMO it is exactly that… Industrial Strength.   The Windows Installer Team, back when they still blogged,  actually made reference to a certain Industrial Strength Household Name MSI Editing Tool (ISHNMET).   There are things I like about WiX (despite being unfairly accused of being a troll for pointing out the obvious) and there are things that I could see WiX simply was never going to do.  I’m sorry, I don’t want to use Notepad++ or VIM to write my installers.  There are things that InstallShield does very, very well.   My ideal setup development tool uses an XML/XSD based language with extensions and compilers but also had an automation interface and graphical designers for developer productivity.   Simply put, IMO,  InstallShield and WiX should not be mutually exclusive. Hence  IsWiX.

Version one was all about authoring merge modules to be consumed with InstallShield.  This was because that’s what the business needed and what they paid to build.  Version two added the concept of Visual Studio project templates to begin to provide scaffolding for installer projects using nothing but WiX.  Today I release version three which adds support for shortcuts and services.  Today IsWiX can be used to support three major stories:  Windows Application, Windows Service and Web Application.  It is possible to create basic installers for all three without writing a single line of XML.

So what does the future hold?  Well, it’s hard to say for certain since I really don’t have a development team.  Personally I’d love to create some great webinars to explain MSI, WiX and IsWiX.  It’s still too hard to get up to speed in this space despite the technology being so mature.

Anyways, thanks for reading this far and I hope you like our latest release.

WiX v3.10.1124.0 Release

The WiX Toolset team did their first v3.10 weekly release: v3.10.1124.0

Weekly releases are basically developer beta test builds and are not final releases.  This release is interesting to me because it includes Visual Studio 2015 support.  I’ve tested this build with VS2015 Preview and IsWiX 2.5.14324.3  and I find everything is working just fine.  I can now relax knowing that I’m well ahead of the curve in supporting the next release of Visual Studio.

IsWiX 2.5.14324.3 Released

When IsWiX was first developed, we targeted Visual Studio 2008.  I dove into VS extensibility trying to figure out how to get the addin story to work.  I got it to work but the solution left a little bit to desire.  The first problem was very embarrassing:  the icon was a big smiley face.

The API / method that registered the addin with the menu supported 2 techniques. One was an orginal index from a Microsoft Office icon library and the second involved creating a resources dll.  I didn’t have the skill or the time to go down the second road so I stuck with the smiley face telling myself that I’d go back and fix it.  As the days, weeks, months, years went by I failed to do so.

The second problem was that occasionally Visual Studio would just decide to drop the addin from the menu.  You had to run a devenv /resetaddin command to get it back.

Today a new version of IsWiX is released that solves these problems.  I’ve scoped the “old” addin to VS 2008, 2010 and 2012 and created a “new” addin using VSIX extension that targets VS 2013 and 2015.  This new extension registers IsWiX in Help | About and Tools | Packages and Extensions and gives a nice blue flame icon with the new text “Launch IsWiX” under the tools menu. 

That’s right, IsWiX now supports VS2015!  There is a caveat though.  The IsWiX multiproject solution templates ride on top of WiX infrastructure.  WiX as of v3.9 does not yet support VS2015 so although IsWiX has correctly registered with VS2015 the project templates will not show up until WiX is ready to support VS2015.    We are way ahead of the curve though so I expect all of this will come together prior to VS2015 shipping next year.

I’m sorry for letting the yellow icon live for so long and for doing back to back weekly releases.  I finally get a fired up on this issue making it now or never.

Development using Free Tools

Three and a half years ago, I wrote an article titled Installation Collaboration Workflows using Free Tools. I’d like to add a few comments based on recent events.

Over the past couple of years Microsoft has been doing some really cool things to help out the community. The first was making Visual Studio Online ( Cloud hosted Team Foundation Server ) free to teams of 5 or less. This is a really big deal because now you have “process in a box” infrastructure provisioned in minutes that features high availability, monitoring and disaster recovery all for the low, low price of…. FREE!

In the past Microsoft had Visual Studio Express for free but it lacked the ability to extend the IDE. At the same time they had the Visual Studio Shell which did. This created a way of developing .NET applications and packaging installers for them but in a very disjointed manner. Now Microsoft has released Visual Studio Community Edition which is on par with Visual Studio Professional. Now you can do both your application coding, installer coding and connect to that shiny TFS cloud instance for the low, low price of…. FREE!

Additionally Microsoft has open source the .NET core libraries. Awesome!

Windows Installer XML has been free and open source for 10 years. IsWiX has been free and open source for nearly 5 years. Combine all of above and a independent consultant like myself now has everything needed to be productive without spending a whole lot of money. A laptop, internet connection and a guest bedroom corner office is all you need to either start a business or give back to your favorite open source project.

Looking back over the past year, I’ve written 95% of my installers using WiX and 5% using InstallShield. I still like InstallShield but the ROI just isn’t there for most of my customers. I’ve been approached by many customers who were about to purchase InstallShield and after a needs analysis I explained to them that I could author their MSI using WiX for a fraction of the cost of the InstallShield license alone. To do setup development collaboration with InstallShield you have to invest thousands of dollars in multiple licenses of DRM laden proprietary software. To do it using WiX and IsWiX is free and integrates into a development ecosystem (Visual Studio) already understood by your customer.

Thanks for reading. Please feel free to reach out to me if you want more information on this topic.

IsWiX 2.4.14319.1 Released

I’m sorry that I haven’t been blogging or working on IsWiX much this year. There just isn’t a lot of time left over after my day job, consulting, passion for SCUBA diving and family time. Still, I’ve managed to get a small release of IsWiX released on our CodePlex site today. This release adds support for authoring 64bit components, parses the MSI Product Version automatically when using TFS 2013 and has some minor improvements to the Files and Folders UI.

WiX DTF Behavior Alert

I was troubleshooting an installer today when I came across what I consider to be a bug in Windows Installer’s DTF managed custom action pattern. First a little backstory: WiX DTF Managed Custom Action projects allow you to add project items as content. During the build this all gets packed into a self extracting custom action that then gets stored in the Binary table of your MSM/MSI. At runtime the binary is extracted to an MSI determined temp directory and a native hook is invoked. This native code then extracts the contents of the self extracting CA into another temp directory and then launches a routine that eventually results in your managed code running. It also sets the current directory of the process to this temp directory so that your content resources can be referenced. That’s how it’s supposed to work. Or at least that’s how it’s always worked. The WiX team doesn’t really document this so I’m sure the “functions as designed” or “functions as coded” door is cracked slightly open. Ok, so the behavior I want to alert you in is if the Microsoft.Deployment.WindowsInstaller.dll (interop library that DTF uses to marshal MSI API calls to the custom action) is in the GAC the current directory won’t be the temp directory as expected, it’ll be the directory in the GAC (C:windowsassemblyGAC_MSILMicrosoft….) that the assembly is stored in. This means any relative path references to your content files will now fail. Ok, so how do you protect yourself? Add this line to the beginning of your custom action: Environment.CurrentDirectory = new FileInfo(Assembly.GetExecutingAssembly().Location).Directory.FullName; This will ensure that the current directory is set to the directory that your assembly was extracted to. I believe this is the first DTF bug I’ve seen in about 3 years. The last was a race condition fixed in 3.6 or 3.5 that randomly prevented a CA from firing. The only before that was back around 2008 and involved custom action sandboxes being recycled and previous custom actions changing the current directory to a directory you wasn’t expecting. I believe it was back then that DTF added a current directory initialization pattern and it generally works well except for the gotcha I just noticed. Update 6/28/2014: Just one day after reporting the bug, Sean Hall has submitted a pull request and the issue has been marked as fixed for WiX 3.9. I’m not sure when 3.9 is going to ship but I’m very thankful and impressed with how quickly this bug was addressed. Thanks guys!

Visual Studio Installer Resurrection

Like a late really, really bad April Fool’s joke, Microsoft announced the day before Good Friday that Visual Studio Deployment Project have been raised from the dead. See:

Visual Studio Installer Projects Extension

I guess the thousands of ignorant developers at User Voice (Bring back the basic setup and deployment project type Visual Studio Installer) and the departure of all the Windows Installer experts from  Microsoft was finally too much to keep a bad thing dead.


If you read this and decide to use this tool anyways, keep in mind:

1) .VDPROJ doesn’t support MSBuild so don’t expect a decent TFS Build story without some custom plumbing to call DevEnv to build the project.   Also don’t expect this extension to be the Visual Studio Online build servers.

2) Read my old article Redemption of Visual Studio Deployment Projects for tips on how to get the most out of the tool without letting it suck the life out of your soul.  (A little bit of VDPROJ and a whole lot of WiX / IsWiX!)

Think I’m being dramatic? Read Change Change Change.  I literally spent a year banging my head against the wall trying to make this technology create installers that rival anything and everything that MSFT DevDiv puts out.  I know this tool better then they do and I can say with complete confidence that it sucks.

But Chris…. you didn’t even try it!

Actually, yes, I did try it.  Installed the extension, created an empty installer and attempted to build it.  Every time I do  Windows Installer kicks off a Visual Studio 2013 repair and the application log indicates:

Detection of product ‘{9C593464-7F2F-37B3-89F8-7E894E3B09EA}’, feature ‘Visual_Studio_Professional_x86_enu’ failed during request for component ‘{CBB86C09-565A-43CF-9120-9D45AE3374CA}’

But Chris…. why do you care what other developers use?

Because I care passionately about the state of the setup industry and at my day job we often receive poor quality installers from third parties that we are then expected to somehow deploy without any issues.

Still don’t believe me?  Go read the comments in this old blog post: WiX in Visual Studio Nearly 8 years have gone by and none of the problems in the tool mentioned in the 100+ comments have been fixed.

Just consider that the $.02 of an 18 year industry veteran who is the Windows .NET  ALM & Deployment Architect for a Fortune 35 retailer with $70B a year in revenue.  We probably have a store very near you and we work hard to make sure that software is delivered to the business flawlessly and on schedule every time.