Category Archives: Uncategorized

IsWiX 4.11.17128.2 Released

IsWiX 4.11.17128.2 is now available here.

A few months ago I mentioned our Visual Studio 2017 Support Roadmap.    Microsoft introduced many breaking changes in VS2017 including breaking an existing installation of VS2015 by deleting EnvDTE from the system.  Wow, I guess they don’t remember their own Component Rules they wrote 20 years ago to address DLL hell.

To be honest, with VS2017 problematic and the WiX team was debating what their plan was going to be, I didn’t really have a plan. (Is hope a plan?)    WiX ended up taking the approach of splitting Votive out of their bootstrapper.  I personally think this is a bad user experience but oh well.

With VS2017 shipped on March 7 and WiX shipped on May 5 I decided it was time to take a look and see what the way forward would be.  At first I started down the path of writing a custom action to call the new COM interop provided by the VS team when I realized that the WiX team had already done this work in the VS extension.  Sweet.   Then I hit another wall.  Visual Studio no longer scans the ProjectTemplates directory when you call DevEnv /setup.


At the end of the day I rewrote the VS Extension to distribute the project templates as part of the VSIX manifest deployed via MSI.  The end result?  An ISWIX installer that behaves just like it always has.  No  bootstrapper,  no separate VSIX packges… just one MSI that registers the AddIn and Project Templates for one to many Visual Studio 2010 – 2017.

Man I love it when a plan comes together!  OK, fine, I love it when I just get lucky every once in awhile.   So there you go, IsWiX now supports VS2017.  You can get it here.

IsWiX 4.1.17105.1 Released

IsWiX 4.1.17105.1  has been release and can be found over here at GitHub.


Yes, GitHub. Although we’ve been happily using CodePlex for the past 7 years we are being forced to move because Microsoft has decided not to bother trying to compete in this space. It’s a shame because CodePlex used to be the .NET platform of choice and could have been easily updated to support Git since TFS/VSTS supports Git.

This attitude from the new Microsoft is also why I was forced to move my company website to HostGator / WordPlex.  The Office 365 team decided they weren’t going to bother supporting SharePoint public websites anymore even though I was perfectly happy with that product also.  I figured I might as well switch from Blogger to WordPress while I was at it.

With all that out of the way…..  So, what’s in this release you ask?

  • Support for FG-WiX / WEP  AppX packaging.  ( This will be it’s own blog article soon. )
  • An anonymous IsWiX user contributed funds for me to purchase an ISWIX LLC code signing cert so that IsWiX could be signed once again.  Thank you!   I’m sorry it took a few months, dealing with Dun and Bradstreet is a real pain.
  • Migration to GitHub.

The AppX packaging is an interesting new feature and our first support for a WiX feature that isn’t available in the FOSS version of WiX.  I paused when considering to do that feature but thought it would be interesting and useful enough to go ahead and do it.


IsWiX Visual Studio 2017 Support Roadmap

I just wanted to put an FYI out there that IsWiX will not support Visual Studio 2017 at launch date.  Microsoft has made substantial changes to the way VS is deployed and created a lot of complications for extension developers.  

In order for IsWiX to function in VS 2 extensions need to be installed:

WiX Votive
IsWiX AddIn

The WiX votive is required to load .wixproj based projects in your solution and is the foundation for IsWiX’s own multiproject solution templates.

The IsWiX AddIn is required to send a .wxs document to the IsWiX.exe.

WiX appears to be moving in the direction of removing Votive from their installer and shipping it separately via the VS marketplace.    Assuming the work is completed (there is currently no ship date announced for v3.11.0)  it will likely require the setup developer to do an additional installation step prior to being able to load an existing solution or create a new one.

As sub optimal as this is, it appears to be set in stone and I have no intention of spending any energy on IsWiX until  I see the final landscape of what I have to deal with.  I will likely do something similar to what they are doing or I might make a bootstrapper  to automate installing WiX, the votive extension and the IsWiX AddIn extension.

FWIW, while this has been the worst, ever release of VS has caused pain for me as either a user of WiX or a user of InstallShield.  It just takes time for this to catch up.   For this reason I *ALWAYS* recommend keeping your application projects in one solution and your installer projects in another.  This way you can ensure you won’t be blocking your application developers from moving forward to the latest version of VS while you continue to compile against the tried and true version you’ve always used.     They need to be cutting edge,  we do not need to be.

IsWiX 4.0.17001.1

Happy New Year!
I’ve published a new version of IsWiX with a pretty important (to me and a few of my customers) bug fix.  I actually did the work yesterday and couldn’t decide if I wanted it to be the only release of 2016 or the first release of 2017.  Silly, I know…  that and the evenings festivities were calling.
Anyways let’s talk about the fix.  The files and folder designer code is a bit scary.  I didn’t write it and I appreciate the efforts of the person that did.  That said,  it had a pretty bad performance issue.  Most people only put a handful of directories and files in any given merge module so most people would have never seen it.    However if you are working on website and find yourself dealing with 1000 directories and 10,000 files in a single merge module it suddenly becomes quiet unusable.
But first a back story….
Many people probably don’t know that IsWiX had a design goal of creating sorted documents with deterministically unique (predictable)  Id attributes and GUIDs.   The reason for this was the company I worked at did *A LOT* of branching and merging and we wanted to make it as easy as possible to branch and merge IsWiX generated .WXS files.  
So every time Files and Folders updates it’s model it resorts the XML.  This usually isn’t a problem. However on really large documents it can take 5-10 seconds depending on machine performance.  When doing a drag and drop the process would go something like this.    Write the XML for a directory, sort,  process subfolders recursively.   So if you dragged a folder with say a 1000 subfolders you would see it get visibly slower and slower until it bogged down so bad you walked away hoping it would finish or just terminated the process.
I’ve done a simple fix remove the sort step and do a final sort at the end.  Now you see it update all the directories in the UI very quickly,  a 5-10 second wait as it does the sort and done.   If your documents aren’t that large  you probably won’t notice a difference at all.
You can get the new release here.
PS- It seems certain browsers have been complaining about anything downloaded from CodePlex. That really sucks.  IsWiX (and the WiX Toolset) is as safe as always.  If you have problems downloading just use a different browser.  If you still get issues be sure to “unblock” the file before installing.

AppX for Native Apps Thoughts

Five years ago, I wrote two blog posts where I explored the possibilities of AppX:

AppX Just Might Work

AppX Just Might Fail

I don’t work in Redmond or Schaumburg Itasca so I tend to not get caught up in the hype of new technologies and instead focus on what works for my customers TODAY.   Over the next few years Windows RT came (and went)  and the Windows Store continued to be pretty much irrelevant.  About a year ago there was some chatter of a Project-C.  I continued to have that “meh” feeling.

The a few months ago I read about some work that the Windows Nano team was doing to support installing per-machine  native apps using extensions for AppX.  Additionally the FireGiant team was developing an extension to support creating MSI and AppX from a single source code base.   Now I found this  REALLY interesting except that I don’t have any apps to deploy to Windows Nano Server.

Along comes BUILD2016 and FireGiant is now posting about creating MSI for Windows 8.1 and below and AppX for Windows 10  DESKTOP applications.  Flexera is also sending similar messages.   Ok, I’m really interested now. 

So it seems now some five years later that AppX just might work!

I am wondering what FireGiant will charge for this capability though.  It’s kind of sad to not see it in the core WiX Toolset as open source goodness.  Rob and Bob, like the rest of us, do have mortgages to pay after all. Maybe there will be options similiar to Visual Studio Community Edition for small business, open source and educational uses.

Slightly off topic I’d like to tie this into another possibly over hyped technology: Chocolatey

I want to like chocolatey. I really do.  I also want to like One-Get Package Management.  However the former is just a wrapper for installers of various quality  and the latter was never really finished and updated to support the latest chocolatey client.

Before anyone gets too offended… I’m not discarding chocolatey yet.  I’m wondering allowed… what if in a few years time everyone is on Windows 10  (Microsoft is pushing it hard after all),  most Choco packages are really AppX wrappers and Packge Management has excellent chocolatey support.

While I’m dreaming… What if we had a way of white listing choco packages in SCCM Software Center?   Oh the possibilities.

So in closing, while new and “modern” (oh I dislike that term)  usually disappoints me, I’m seeing reason to be optimistic today.   There could be a sea change coming to my world view soon.

IsWiX4.0.15284.1 Released

A month ago I announced a new version of IsWiX with support for WiX v4.0.  At the time I wrote the warning:

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.

Sure enough, one of my updates did, cough, “suck”.  It seems I didn’t test all of my designers, rather only the ones that appeared.  I missed the fact that one of them wasn’t showing until I needed it to do some work for a client.  I opened up IsWiX and went to define a custom table and was really disappointed that it wasn’t there.  So I followed my own advice and downgraded to IsWiX 3.0, kept calm and carried on.  Eventually I had some time to go look at it and sure enough the IsValidContext() member simply needed to be refactored.  

The new and improved IsWiX can be found here.

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.