EzDevInfo.com

How to pass CustomActionData to a CustomAction using WiX?

How are properties set on CustomActionData to be retrieved by a deferred custom action?

How to implement WiX installer upgrade?

At work we use WiX for building installation packages. We want that installation of product X would result in uninstall of the previous version of that product on that machine.

I've read on several places on the Internet about a major upgrade but couldn't get it to work. Can anyone please specify the exact steps that I need to take to add uninstall previous version feature to WiX?

Automatic vs Automatic (Delayed start) [closed]

When installing Windows Services there are two options for Automatically starting a Windows Service on Windows startup. One is Automatic, the other Automatic (Delayed start). My question is what is the difference between these two in detail?

For example, if you're creating the installer with wixtoolset, the ServiceConfig element has the DelayedAutoStart attribute. How will that effect what happens when services are started at boot time?

Wix documentation: http://wixtoolset.org/documentation/manual/v3/xsd/wix/serviceconfig.html

How to add a WiX custom action that happens only on uninstall (via MSI)?

I would like to modify an MSI installer (created through WiX) to delete an entire directory on uninstall.

I understand the RemoveFile and RemoveFolder options in WiX, but these are not robust enough to recursively delete an entire folder that has content created after the installation.

I noticed the similar Stack Overflow question Removing files when uninstalling WiX, but I was wondering if this could be done more simply using a call to a batch script to delete the folder.

This is my first time using WiX, and I'm still getting the hang of custom actions. What would be a basic example of a custom action that will run a batch script on uninstall?

How can I set the WiX installer version to the curent build version?

I wrote an application and its WiX installer and put it under version control using subversion. When the WiX installer builds I want its version number to be the current build version of the application. How do I accomplish this? I used c# to code the application.

N.B. I am using ccnet to build this project

How to Enable WiX Projects in Visual Studio 2015

When I go the the New Project dialog in Visual Studio 2015, Windows Installer XML isn't available. How can I enable WiX projects in Visual Studio 2015?

Removing files when uninstalling WiX

When uninstalling my application, I'd like to configure the Wix setup to remove all the files that were added after the original installation. It seems like the uninstaller removes only the directories and files that were originally installed from the MSI file and it leaves everything else that was added later in the application folder. In another words, I'd like to purge the directory when uninstalling. How do I do that?

WiX undefined preprocessor variable

I'm starting to use WiX in order to do automated builds to create msi's of my c# projects and am experiencing the error "Undefined preprocessor variable '$(var.MyProject.TargetDir)'"

I am using the latest WiX v3.0.5419. Inside my wxs file I am trying to use pre-processor variables that are listed on this webpage (http://blogs.msdn.com/jrock/archive/2008/01/29/complete-list-of-candle-preprocessor-variables.aspx)

<Component Id="MyId" Guid="MyGuid">
   <File Id="MyId" Name="MyName" KeyPath="yes" 
      Source="$(var.MyProject.TargetDir)\MyName.dll" />
</Component>

I have added the reference for MyProject to the .wixproj and if I open it up in Notepad I can see the reference.

<ItemGroup>
  <ProjectReference Include="..\MyProject.csproj">
    <Name>MyProject</Name>
    <Project>{guid}</Project>
    <Private>True</Private>
  </ProjectReference>
</ItemGroup>

This is my nant build script that I use to create the msi. Maybe it's because the .wixproj knows about the project reference which isn't used in the build?

<exec basedir="${tools.wix}" managed="true" program="candle.exe">
  <arg line='-out "${tools.wix.objfile}"' />
  <arg value="../MySetup.wxs" />
</exec>

Can anyone enlighten me on this please?

Installers: WIX or Inno Setup?

I'm comparing these two tools. The impression I have is:

• Inno Setup does not produce an MSI, but can do everything WIX can do
• WIX does produce an MSI, but has a steep learning curve

Do you agree with this characterization? What other differences are there? How does WIX# shake-up this story? Since Inno Setup does not use the windows installer, does it have difficulty with uninstalls? Can Inno Setup, upon command, downgrade an installation to an earlier version - or can it only install / upgrade applications?

Replicating Visual Studio COM registration with a WiX Installer

Once upon a time, a young, naive engineer thought it would be a good idea to separate out some of the functionality for his app into a COM component, written in C#. Visual studio had all the tools to do that, right? .NET was practically made for this, right? HA! He said, this will be easy. I'll have decent separation of components, keeping business logic away from the front end, and with COM, I'll be able to use it from anywhere! He merrily checked the register for COM interop checkbox in the project properties, exposed the classses he wanted, and went on his way.

Oh, the trials such a choice made. The young engineer now, more experienced, would not now wish this upon anyone. However, the burden had been placed upon his shoulders, and the burden remained heavy. He looked to lighten the load.

Along came WiX, a tool for generating Windows Installer files from XML. This intrigued him - it could replicate, quite simply, most of the code needed for a proper windows installer file simply from a handful of configuration files. His sights were looking up.

With WiX 2.0, he could generate quite easily the files needed to register a C# COM object. This involved using the tool tallow. He'd do something like the following:

tallow -c -nologo MyComExposedLibrary.dll > MyComExposedLibrary.wxs

which would then be fixed up (at first this was done manually, but eventually I recorded the steps into a small tool set the final directory ref id, component ID, fileID, GUID and codebase).

Then, the ensuing installer would install, and there would be joyous celebration, if the app worked.

Which it did not.

For days the young engineer poured over the differences on his development PC and that of the test install PC. "All the registry keys are the same!" He would exclaim. "Everything for MyComExposedLibrary is registerd, I swear!"

Except, it wasn't.

On the dawn of third day, after many a mountain dew, he realized there was one more object that Visual Studio was registering that his installer was not: the MyComExposedLibrary.tlb file.

Visual Studio, apparently, had been registering this file all along, creating additional subkeys in the HKLM\Software\Classes\Interface registry key, and registering the typelib in HKLM\SOFTWARE\Classes\TypeLib.

Tallow gave no help, complaining that a .tlb wasn't a file it groked. Nor the WiX 3.0 beta - this seemed to have even more issues getting things working.

I also gave Heat a try. This generated registry elements and class elements. I cleaned up heat's output, and then went to compile it, but got a different error: error LGHT0130 : The primary key <uuid here> is duplicated in table 'Registry'. Problem is, as far as I can tell, that uuid doesn't actually exist in any of my wxs source files. If I change around the component ref order in my feature element, a different dll component gives that error. Since I have been unsuccessful at getting a WiX 3.0 version of the project to compile, I haven't been able to confirm whether or not heat gives the right output.

I removed everything from the installer except for one of the assembly that cause this error to appear and tried compiling again. I got the same same error. Arrugh!

So, my good fellows, Windows enthusiasts, and WiX users, there falls two questions:

• Is a typelib something that WiX can register natively? If so, how?
• If not, what's the proper way of registering a typelib with a windows installer?

Also, I guess as another part of this, how does Visual Studio determine how to register the typelib? (Edit: looks the MSDN library article on typelib registration has the names of the keys needed, but I still need to figure out how to get the uuid's. (This is from this blog post on typelib and COM registration by Larry Osterman.) ) Reading a bit more, It may fall to me to register these bits manually, but I hope not...

I evaluated the output from regasm /regfile:MyDll.dll MyDll.dll. It looks like these are the same keys that wix generates for the dll. Regasm's other mode, regasm /tlb:<filename> generates and registers the typelib for the assembly, but,

/regfile[:FileName] Generate a reg file with the specified name instead of registering the types. This option cannot be used with the /u or /tlb options

seems the /regfile switch is incompatible with the /tlb switch. Khaaaaaaaan!

Further update: It looks like you don't actually need to include the .tlb file. According to this post on wix's typelib element, an MSI can create/register this as part of the setup process. It all comes down to configuring the WiX document to actually install it by getting the right attributes.

I found out later that you can get the right attributes using heat on the .tlb directly! See this SO question for more information.

how to get wix to update a previously installed version of a program

I wrote an install program with wix and it worked fine to install my program. Now I need to update it, so I bumped up the version number but when I go to install the new program over the old one it complains that an older version is already installed and tells me to uninstall it first.

How do I get it to update or automatically uninstall it before reinstalling?

WiX Includes vs Fragments

• What's the difference between a WiX include (.wxi file) and a WiX fragment (.wxs file)?
• What are the use cases for each?
• Which should be used and why?

How to create a bootstrapper application without a license agreement step

I have created a WiX Bootstrapper project. When the installation runs, it presents a license agreement.

I want to create a bootstrapper without this step as I don't want it to show any license agreement. Is it possible to do it? If yes, how?

Custom WiX Burn bootstrapper user interface?

I'm creating an installation package with WiX 3.6 primarily so I can take advantage of the Burn bootstrapping features. So far I have several MSI packages bundled together that will be installed with the built-in bootstrapper application (WixStandardBootstrapperApplication.RtfLicense).

I have read that Burn allows the default bootstrapper application to be replaced by specifying a custom UX.dll, but I haven't yet been able to locate any resources that describes how the custom ux.dll is constructed (that is, how it integrates with the Burn engine, what technologies do I use, what interfaces should I implement, etc.).

My goal is to create a branded bootstrapper that can collect arbitrary information from a user and pass that information onto the various bundled MSI files, EXE files, etc.

So I have two questions really:

1. To what degree is the default bootstrapper application customizable?
2. Are there any resources available that describe how to construct a custom UX.dll?

WiX ICE validation errors

I'm having some strange issues with WiX on my local machine. The problem is intermittent, but after a few rebuilds of the solution, the WiX project starts throwing ICE validation errors.

If I go into my AppData\Local\Temp folder and delete all the temporary folders that contain the MSI, the solution compiles again. A short while later, the problem starts happening again. Having to keep clearing down the temp folders isn't a sustainable or satisfactory solution.

Has anyone else encountered this issue? The validation error codes seem to always be a combination of ICE30, ICE38, ICE64 and ICE91

Update:

As requested, here are the entries from the most recent failure:

error LGHT0204: ICE38: ICE Internal Error 1002. API Returned: 1615.
error LGHT0204: ICE38: Error 2235: /OU.AppFramework.Includes.msi, _Profile, UPDATE Directory SET _Profile=0
error LGHT0204: ICE64: ICE Internal Error 1001. API Returned: 1615.
error LGHT0204: ICE64: Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD _Profile SHORT TEMPORARY HOLD
error LGHT0204: ICE91: ICE Internal Error 1001. API Returned: 1615.
error LGHT0204: ICE91: Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD _Profile SHORT TEMPORARY HOLD

Interestingly, this failure occurred before I left the office last night, and the solution compiled OK when I came in this morning. As it seems to centre on the temp directory where the MSI is build by WiX, could it be the build process locking the file?

Update 2:

And now we're back to over 600 errors, mostly repetition of this error:

error LGHT0204: ICE30: ICE Internal Error 100. API Returned: 1615.
error LGHT0204: ICE30: Error 2235: AppFramework.Includes.msi, _ICE30SFN, SELECT Directory_Parent, Directory, DefaultDir, _ICE30SFN, _ICE30LFN FROM Directory WHERE Directory.Directory=? AND Directory_Parent<>?

Update 3:

The problem still exists even after trying the suggestion by @limpan. There are a couple of warning given by light that are caused by the MSI output folder being locked when light tries to access the MSI:

Warning 549 The directory '\AppData\Local\Temp\2opu3hxf' is in use and cannot be deleted. light.exe