Geoff's Blog: Converting a Visual Studio Setup Project to Wix

Anyone who’s using Visual Studio 2012 and either opened up an old solution with a Setup Project (.vdproj) or created a new solution and looked for the setup project under project types will know it’s no longer there and no longer supported. This is not actually that surprising since TFS Build Server and MSBuild doesn’t support the legacy .vdproj files any way.

Wix is the recommended alternative; itis very powerful, but quite complicated to work with and there is currently no GUI.

The .vdproj can’t be converted directly, however one of the wix tools called dark can be used to decompile msi files into wxs xml format.

This is a step by step procedure for converting an MSI with an exe, a number of DLLs and files into a Wix project.

1. If you haven’t got Wix, install it and add a Wix project to your solution.

2. Decompile the msi with the following command line:

c:\Program Files (x86)\WiX Toolset v3.6\bin>dark c:\temp\setup.msi -o c:\temp\setup.wxs

Dark will output results like this, there will be a load of warnings like this:

Windows Installer Xml Decompiler version 3.6.3303.0

setup.msi

c:\temp\setup.msi : warning DARK1060 : The _VsdLaunchCondition table is being decompiled as a custom table.

dark.exe : warning DARK1065 : The AdvtUISequence table is not supported by the Windows Installer XML toolset because it has been deprecated by the Windows Installer team. Any information in this table will be left out of the decompiled output.

c:\temp\setup.msi : warning DARK1062 : The ModuleSignature table can only be represented in WindowsInstaller XML for merge modules. The information in this table will be left out of the decompiled output.

c:\temp\setup.msi : warning DARK1062 : The ModuleComponents table can only be represented in Windows Installer XML for merge modules. The information in this table will be left out of the decompiledoutput.

c:\temp\setup.msi : warning DARK1066 : The MsiPatchHeaders table is added to the install package bya transform from a patch package (.msp) and not authored directly into an install package (.msi). The information in this table will be left out of the decompiled output.

c:\temp\setup.msi : warning DARK1066 : The Patch table is added to the install package by a transform from a patch package (.msp) and not authored directly into an install package (.msi). The information in this table will be left out of the decompiled output.

c:\temp\setup.msi : warning DARK1066 : The PatchPackage table is added to the install package by a transform from a patch package (.msp) and not authored directly into an install package (.msi). The information in this table will be left out of the decompiled output.

dark.exe : warning DARK1058 : The AdvtExecuteSequence table contains an action 'MsiUnpublishAssemblies' which is not allowed in this table. If this is a standard action then it is not valid for this table, if it is a custom action or dialog then this table does not accept actions of that type. This action will be left out of the decompiled output.

3. Export binaries using dark.exe:

c:\Program Files (x86)\WiX Toolset v3.6\bin>dark c:\temp\setup.msi -x c:\temp

4. Rename anything that sounds like an icon or bitmap in the outputted ‘Binary’ folder to have a .bmp suffix, I had:

DefBannerBitmap
NewFldrBtn
UpFldrBtn

These should be .ibd files:

MSVBDPCADLL
VSDNETCFG

The icon in the ‘Icon’ folder can be renamed .ico

Copy these folders into the WIX project, include them and set as resources.

5. Fix binary paths from

To:

And

To:

6. Fix project references by adding references to the required projects in the solution like you would in any normal project and then fix the binary components like this (DLLs are similar to EXEs):

</Component>

To:

</Component>

7. Fix file components like this:

</Component>

To:

</Component>

8. Now build and fix any errors. Installers can contain many different components and features so will vary in their complexity to get working.

9 comments:

BretCJ721 February 2013 at 12:12
Geoff - I'm getting everything resolved with my errors after running, but now i'm getting ICE30 errors saying my TargetFile Interfaces.dll is used by two different components on an LFN system, this breaks component reference counting.

Do you know how to resolve?
Geoff Webber-Cross21 February 2013 at 12:32
Have you got the same dll listed twice? If so try taking one out?
BretCJ721 February 2013 at 12:57
Geoff - That looks like the issue, however some of the dll's that are included are 32bit and some 64bit with same name. I found a solution to this by taking out the "Name" attribute on the File Element since the wix documentation said that is optional and if not specified it will use the source name.

http://wix.sourceforge.net/manual-wix3/wix_xsd_file.htm

Thanks for the help, its not compiling!
Geoff Webber-Cross21 February 2013 at 12:59
Hope you mean now compiling?
BretCJ721 February 2013 at 13:07
Yes, small typo.

One last thing. Do you know how I can replace the old source file's it created in the FILES directory with the actual Source location of the referenced files in my solution that i'm still using?

Old:
Source="c:\CDS_Trunk\Main\Testing\SetupProject1\File\_1A182947CFF1124D2FC07F04434C9077"

New: (I think this can work?)
I assume I could just give it a relative path like...
Source="..\Interfaces.dll"

I see it extracted all the old binaries and put them in the FILES directory and gave them names like _31474CA2ED575510B8CF82C2C90CB5BE, which should just be the dll's i'm using for the setup correct?
Geoff Webber-Cross21 February 2013 at 13:12
Excellent B-)

Try this:

Source="$(var.MyApplication.TargetPath)"
BretCJ721 February 2013 at 13:26
Alright, getting closer. When defining my pre-processor variable for the location of the referenced dll from the project I have this below, where CDS.Management.Task.Client is the project name in my solution.

SourceLib=CDS.Management.Task.Client\bin\Debug

My .wxs file contains:
Source="$(var.SourceLib)\CDS.Core.dll"

But my Error windows says:
The system cannot find the file 'CDS.Management.Task.Client\bin\Debug\CDS.Core.dll'

Am i missing someting to define the SourceLib path such as a ..\ ?
BretCJ721 February 2013 at 13:33
Ok, sorry I fixed it. Realized i wasn't giving it a proper file path to the dll.....

This was my fix for the pre-processor var:
SourceLib=$(SolutionDir)Components\Task\CDS.Management.Task.Client\bin\Debug
Unknown10 August 2016 at 20:55
After setting the pre-processor variables, this worked like a charm. Thank you very much for sharing.

Friday, 9 November 2012

Converting a Visual Studio Setup Project to Wix

9 comments: