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.

IsWiX 22.13293.1 Released

I always liked the  Code View / Design View patterns in Visual Studio so I choose to emulate this in IsWiX.  Another aspect of this is to have one source file maintained by a code emitter and another source file maintained manually by the developer using a text editor.  Think  Foo.cs and Foo.Designer.cs  in Winforms or  XAML / CS in WPF.

Usually you can mark up IsWiX authored XML without problems ( add various element such as ServiceInstall, ServiceControl, ShortCut and so on )  but sometimes you need to add an element that might cause IsWiX issues ( Component typically ) or that you want to really add a lot of custom action elements and related sequencing and you really want that code in another file for readability.

To solve this problem I like to create a second .wxs file and use the Fragment element.  Then with the use of ComponentGroup, ComponentGroupRef, DirectoryRef, Directory and Component elements you can tie the two together.   This is sometimes a little hard to explain to a new WiX developer so I decided to make this the default experience in IsWiX merge module projects going forward.   With that said, go check it out here.

IsWiX 2.1.13270.1 Released

As I promised in my earlier blog post today,  IsWiX 2.1.13270.1 is released and be found on CodePlex here.

This release adds support for Microsoft Visual Studio 2013 RC.  The IsWiX Setup and IsWiX Merge Module projects will show up in File | New | Project just as soon as WiX 3.8 supports VS 2013.  Or can follow my instructions linked in my previous blog post.

WiX / IsWiX support for VS 2013 RC

Visual Studio 2013 is set to GA next month and RTM in November.  Based on blog posts and mailing list messages, it seems that the WiX team is now struggling to meet their schedule of a WiX 3.8 beta release with VS 2013 support by Halloween and a final release by the end of the year.  You can read more about it here and here.  My guess is that with Rob leaving MSFT and the DevDiv embracing InstallShield LE that they aren’t getting the VS team support anymore.

I’ve taken a look into what it would take and my initial impression is that there isn’t any difficult VSIX work.  A WiX setup developer with C++ expertise should be able to knock this out for them.  Hopefully John Cooper will be able to step up as he has offered.  If not, please consider jumping on the wix-devs list and see what you can do.

That said, I’ve done some prototyping using manual steps and have come up with some procedures to get WiX 3.7 working on VS 2013 RC.  You can read those steps here.

I have also gone ahead and made all the changes needed for IsWiX to work on VS 2013 RC.  Basically IsWiX interacts with Visual Studio in two ways.  The first is a Tools menu bar AddIn.  To make this work I simply update the AddIn XML to declare that I support VS 2013.   No other code changes are needed as the integration is very simple and no other code changes are required.

The second interaction is that IsWiX leverages WiX infrastructure to provide two additional project template types.  They are very similar to the WiX project types but more built out for a specific purpose. (Convention over configuration covered in my last blog post.)  To get this to work I merely updated the IsWiX installer to locate the location of VS2013 and copy the project template zip files to the right directory followed by a call to devenv /setup.  No other changes were required.

  The problem is that if WiX isn’t properly registered with VS 2013 then the IsWiX project templates won’t show.   There is no error per say… they just don’t appear.

Hopefully WiX 3.8 will be released soon with VS2013 RC support.  In the mean time I will be releasing a new version of IsWiX this weekend with my pieces completed.

Until then, my general recommendation is to never use project references and keep your installer projects and your application projects in different solutions.  This way you don’t box yourself into a corner if some of your projects are ready to upgrade and others are not.

IsWiX 2.0.13013.4 Released

IsWiX 2.0.1310.4 has been published on CodePlex.  I’ve added two new Visual Studio Project Templates that go beyond what WiX proper provides.  These templates along with the WiX designer allows for fast and simple MSI creation using the following simple steps.

1) Create an IsWiX Setup Project and VS Solution.  Example: Notepad
2) Add a new IsWiX Merge Module Project. Name it the same as the project in step 1 except add MM to it.  Example: NotepadMM
3) Add the IsWiX Merge Module Project as a reference to the IsWiX Setup Project.
4) Take a look through the source for any other changes you may need such as CompanyName, EULA, Banner and Dialog Bitmaps.
5) Use IsWiX to author your files into the IsWiX Merge Module Project.
6) Author additional meta into the IsWiX Merge Module Project that’s not supported by IsWiX yet.

I’ve been able to use this process to create a C# Windows Service, create the installer and set up a CI build using Team Foundation Service.  This installer is fully versioned and supports major upgrades. The amount of time needed to author and test is less then 10 minutes!  Here is a short video ( no sound ) to demonstrate.

Windows 8 Changes Setup Developers Need To Know About

I’ve been using Windows 8 for awhile and I like it a lot.  I can’t say I liked the new Start Screen at first but it’s grown on me.  There is room for improvement though.

Anyways, back to installs  Here’s a short list I have for the moment and I’ll come back and grow it as more things occur to me.

1) The Change UAC Settings dialog doesn’t really disable UAC.  You’ll find your command windows aren’t elevated and that you get UAC confirmation when updating files in the Windows directory.  To completely disable UAC you have to go into the registry and change the EnableLUA policy registry value from 1 to 0 and reboot.  I’m not saying you should do this, I’m just saying that if you *STILL* aren’t creating installers that follow best practices with regard to custom action scheduling and execution context  you really, really need to get on board.  (Ahem Visual Studio Deployment Project users ).

2) .NET 2.0/3.0/3.5 is not installed by default.  If you are using managed code such as custom actions that don’t have an activation policy manifest that allows the use of newer versions of the framework they will blow up.  (Ahem Visual Studio Installer Class Custom actions users)

3) Installing .NET 2.0/3.0/3.5 on Windows 8 is a pain in the back side.   You can’t use the EXE redist, you have to use a dism command to enable the feature.  However,  Microsoft didn’t include the bits in the install.wim so it has to be able to go out to Windows Update and download source. In other words it’s  web/wsus enabled (via the OS) install only.   There is no standalone installer (MSU) that I’m aware of.    This is a sore spot and is best cured by moving your code forward to .NET 4.0 or beyond.

4) The new start screen shows all icons by default.  The user can create groups (think groupbox )  but they can not create subfolders and zoom into to see the icons.  In other words,  if your installer creates a bunch of icons and you thought that was ok because you were putting them into subfolders to hide them, they will all appear and the user will have to unpin a bunch of shortcuts to clean up his desktop.  (InstallShield, Visual Studio…  lots of icons )   To prevent your installer from doing this, set the System.AppUserModel.StartPinOption to 1 using the MsiShortCutProperty table.

Those are my three biggies so far.  As I discover more, I’ll keep you posted.