How to target 32bit and 64bit a .NET applications with WiX and separate MSI packages

Target 32bit and 64bit .NET applications

This post will explain how you can build msi packages using WiX for both 32bit and 64bit platforms.  The goal is to create 2 different msi packages. One for 64bit systems, which will install the program in to c:\Program Files on 64bit, and another msi package that will install the program in to c:\Program Files on 32 bit systems. The .NET application itself will be compiled with CPU target Any, which results in that it will run in 64bit mode on 64bit systems and 32bit mode on 32bit systems. Of course, you could also install the 32bit msi package on 64bit systems, which will end up being installed in c:\Program Files (x86).


Microsoft Visual Studio 2008

In my environment, I used 64bit Windows7, so I installed the 64bit version of WiX build 3.0.5419.0-x64-setup

Create a simple .NET application

We will create a simple .NET Winforms application that will show some platform information, like this:



We will also create a WiX setup project and configure a new platform type in Visual Studio for the 64bit target.

Fire up Visual Studio and create a new Windows Forms project:


Add 3 labels to the form:


Add code in the Form Load event to fill the labels with info:


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
using System.Diagnostics;
namespace WindowsSetupTest
public partial class Form1 : Form
public Form1()
private void Form1_Load(object sender, EventArgs e)
label1.Text = "Platform: " + System.Environment.OSVersion.Platform.ToString();
label2.Text = "Is 64bit OS: " + Is64Bit().ToString();
label3.Text = "Is 32bit process on 64bit OS: " + Is32BitProcessOn64BitProcessor().ToString();
[DllImport("kernel32.dll", SetLastError = true, CallingConvention = CallingConvention.Winapi)]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWow64Process([In] IntPtr hProcess, [Out] out bool lpSystemInfo);
private bool Is64Bit()
if (IntPtr.Size == 8 || (IntPtr.Size == 4 && Is32BitProcessOn64BitProcessor()))
return true;
return false;
private bool Is32BitProcessOn64BitProcessor()
bool retVal;
IsWow64Process(Process.GetCurrentProcess().Handle, out retVal);
return retVal;


Create a Wix project

Add a new project to the solution, a WiX Setup project:


In the Product.wxs file, enter the following code:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="">
<?define InstallName  = InsomniacGeek ?>
<!-- Product name as you want it to appear in Add/Remove Programs-->
<?if $(var.Platform) = x64 ?>
<?define ProductName = "InsomniacGeek: Windows Setup Test (64 bit)" ?>
<?define Win64 = "yes" ?>
<?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
<?else ?>
<?define ProductName = "InsomniacGeek: Windows Setup Test" ?>
<?define Win64 = "no" ?>
<?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
<?endif ?>
<Product Id="*" Name="$(var.ProductName)"
Language="1033" Version="1.0.1"
<Package Id="CC76D2EF-6A0A-468e-89D6-6953AAEFCD06" Keywords="Installer"
InstallerVersion="200" Compressed="yes"
<Upgrade Id="2551D901-A700-484b-B35C-B8E3D358FE73">
<UpgradeVersion Minimum="1.0.0" IncludeMinimum="yes" Maximum="1.0.1" Property="OLDERVERSIONBEINGUPGRADED"/>
<UpgradeVersion Minimum="1.0.1" OnlyDetect="yes" Property="NEWERVERSIONDETECTED"/>
<Media Id="1" Cabinet="" EmbedCab="yes" />
<Condition Message="A later version of [ProductName] is already installed. Setup will now exit">
<!-- Program Files \ App \  -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="$(var.PlatformProgramFilesFolder)">
<Directory Id="INSTALLLOCATION" Name="InsomniacGeek">
<Directory Id="APPLICATIONROOTDIRECTORY" Name="Windows Setup Test"/>
<!-- Start Program menu -->
<Directory Id="ProgramMenuFolder">
<Directory Id="ApplicationProgramsFolder" Name="InsomniacGeek Windows Setup Test"/>
<!-- Files in app path -->
<Component Id='MainApp' Guid='9D181A16-5383-45b8-9D13-A0781060CA16'>
<File Id='MainApp' Name='WindowsSetupTest.exe'
DiskId='1' Source='..\WindowsSetupTest\bin\Debug\WindowsSetupTest.exe'/>
<!-- Shortcut -->
<DirectoryRef Id="ApplicationProgramsFolder">
<Component Id="ApplicationShortcut" Guid="953BEB35-E0BB-40ae-A1C8-F8A88E1E2529">
<Shortcut Id="ApplicationStartMenuShortcut" Name="Windows Setup Test" Description="Application for testing"
<Shortcut Id="UninstallProduct"
Name="Uninstall the InsomniacGeek Windows Setup Test"
Arguments="/x [ProductCode]"
Description="Uninstalls InsomniacGeek Windows Setup Test" />
<RemoveFolder Id="ApplicationProgramsFolder" On="uninstall"/>
<RegistryValue Root="HKCU" Key="Software\InsomniacGeek\WindowsSetupTest" Name="installed" Type="integer" Value="1"
<!-- Features -->
<Feature Id="Complete" Title="Windows Setup Test" Level="1"
Description="The complete package"
Display="expand" ConfigurableDirectory="APPLICATIONROOTDIRECTORY" >
<Feature Id="MainProgram" Title="Program" Description="The main executable" Level="1">
<ComponentRef Id="MainApp"/>
<ComponentRef Id="ApplicationShortcut"/>
<RemoveExistingProducts After="InstallInitialize"/>
<!-- UI -->
<UIRef Id="WixUI_Mondo"/>
<UIRef Id="WixUI_ErrorProgressText" />
<!-- End UI -->


And add references to WixUIExtension.dll and WixUtilExtension.dll.

What you will notice now is that you have 3 targets in your configuration:


The value you choose here will be transferred to the Platform variable in WiX. Unfortunately, the 64bit option is missing, so we must create that one.

Create a x64 configuration entry

Select the Configuration Manager.


Select  <New…>



Select the x64 option and click Ok.


When you now build the Wix project, the output will be created in a new x64 folder. In the Product.wxs code, we also have a title that indicates that is runs in 64bit mode:



When installed, it will end up in c:\Program Files, just as we wanted.

The 32bit version of the msi is built when you select the x86 platform target




Hope this shed some light on how to deploy .NET applications for multiple targets.

Download the complete solution here.

SharePoint: Solution still deployed after retracting it

Solution still deployed after retracting

You maybe have stumbled upon this scenario: Solution still deployed after retracting it.

After you have retracted your SharePoint solution in Central Administration, the solution flips back to deployed?

The issue seems to be that when you have deployed your solution with –allcontenturls, which means it will be deployed to the Central Administration web application as well, you must specifically retract the solution from the Central Administration web application.

So here are the steps to work around this issue:

  1. Retract the solution from all content URLs
  2. Retract the solution from the Central Administration web application specifically

A problem occurred when Windows tried to activate. Error Code 0x8007232B

You may have encountered an issue when trying to activate your copy of Windows Server 2008 R2.


Select Activate now.


Select Activate Windows online now.


You get this error message, with Error Code 0x8007232B.

To get around this problem, open an elevated command prompt and type the following command:

slmgr -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx


Where the x’s are your license key.

After you have done that,  you can active successfully.

This information is taken from Microsoft KB929826

Getting Access denied for User Profiles and Properties

If you get access denied when trying to access the User Profiles and Properties page in SharePoint Central Administration,

you need to add the account you are using to the Manage Profiles in Shared Service Rights.

In Central Administration, go to your Shared Services page. Under User Profiles and My Sites, click on Personalization services permissions. Add the account your are using and select  Manage user profiles.