WiX Custom Actions and Entity Framework Migrations

Working on a new project I had a need to integrate Entity Framework 6 migrations as part of the installation package.   My goal is simple, a single installer that migrates and rolls back the database as part of it’s installation procedure.   The key to making this work is a utility that is part of the EF6 Nuget package – Migrate.exe.

path to migrate

To find this tool, simply navigate to your solution folder, then packages, then EntityFramework.<version>, then tools.   Here you will find several files, one of which is the migrate.exe tool being referenced here.

MSDN provides a healthy dose of information on the specifics of how to use migrate.exe, but for my purposes, I am going to collect the connection string from the user.   The software in my case supports only SQL Server, so I can default the provider as such.  So, this makes the “provide connection string” approach — the last one in the linked article — the perfect option for my needs.

provide connection string example

Armed with this tool I went to work creating my UI dialog for WiX.   This dialog will allow me to capture the connection string information.   I had previously used an article from code project to learn about the WiX dialogs.   I used that same code here in order to create my connection string dialog.

With the dialog fragment in place.  It was a fairly simple matter to integrate it into the WiX workflow.   Note: I am using WixUI_Mondo as my UI.

This created the desired result.

Now it was a matter of using Migrate.exe to push the entity information out.  In order to do this I needed a custom action.  So I added a new CA project to my solution, and referenced it in my installer.   For brevity of this post, I’ve removed all of the logging from this object.

A few key points about this method:

  1. It requires some property values to be passed into the custom action as part of the WiX markup, particularly the connection string – which comes from our custom dialog, and the executable path – which comes from the directory structure definition.
  2. Because I’m working with a connection string, I have to do some trickery as the ‘;’ plays havoc on the property values being passed in because the CA uses this same sentinel as a delimiter for the values.   This basically means if I have a connection string “data source=localhost;initial catalog=database_name;integrated security=true” it will come through as multiple values into the custom action, splitting on the ‘;’.
  3. It will execute a shell (i.e. a command prompt window will popup during installation).  For me this was ok, and beats the alternative – which is:  You can opt to not use shell execute.  However, this means you also cannot redirect output, which means you cannot log output in a verbose debugger session (msiexec /l switch).

 

When I get the chance, I’ll try to post a sample on my github page, and update this post with the link.