Wix write port to etc/services file - wix

Question

I am replacing an old installer with a new one using Wix 3.8.
The old installer inserts a line in the file %SYS32%\Drivers\Etc\Services and that seems simple. However I have not found any easy way to add new information to a text file using WiX. So I am thinking that maybe there is some other way to do this - i.e. not to use the services file, but to register the port using some other setting in Windows, for example to Write to the Registry which is simple with WiX.
Anyone know how to do this?
Otherwise, any tip on any Custom "FileWriter" for Wix? The only one I have found can only write using a template file and that is not what I want. I could of course write my own, but this feels like reinventing the wheel...
Thanks!
/Tomas

Answer 1

For writing to a file, you can create a dynamic-link library that includes the method which will do the things you want to be done (editing files...etc.). And then you can create a Type 1 custom action which calls a method from a dll file. Technically, a Type 1 action means authoring an unmanaged C/C++ dll (Windows Installer does not natively support .NET actions), but you can use C# Custom Action project (that comes with WiX extension) which creates a C/C++ dll from managed C# code.
aCustomAction.cs
using System;
using Microsoft.Deployment.WindowsInstaller;
namespace someLibrary
{
public class CustomActions
{
[CustomAction]
public static ActionResult MyFunction(Session session)
{
// do something
return ActionResult.Success;
}
}
}
ActionResult return type notifies the installer whether the action succeeded or failed. Please note that you can use 128 custom actions per CustomAction project (16 before Wix 3.6).
When the project is compiled, you will have a .dll and a .CA.dll file. You should reference the second one (which includes unmanaged code) in your wix project by adding the following lines to Product.wxs:
<Binary Id="aCustomActionDLL" SourceFile=".\aCustomAction.CA.dll" />
or you can directly reference from the project using $var.
Finally, you can use CustomAction element's BinaryKey and DllEntry attributes to specify method to call:
<CustomAction Id="CA_aCustomAction"
BinaryKey="aCustomActionDLL"
DllEntry="MyFunction"
Execute="deferred"
Return="Check" />
Then you schedule it to run:
<InstallUISequence>
<Custom Action="CA_aCustomAction" After="CostFinalize" />
</InstallUISequence>
The dll files will not be installed to user's computer; they perform their duty yet they stay inside the MSI package.
As an alternative you can create a full executable, then run it as a custom action (Type 2, Type 18 or Type 34). I recommend type 2 since it embeds the exe file into MSI:
<Binary Id="yourProgramEXE" SourceFile="source.exe" />
<CustomAction Id=""CA_ProgramExe"
BinaryKey= "yourProgramEXE"
Impersonate="yes"
Execute="deferred"
ExeCommand=""
Return=""check />
Impersonate tells the installer whether to impersonate the user who launched the installer or not. If it is no, you action will run as LocalUser. Immediate actions do not need impersonation and you will get an ICE68 warning if you set it to no in an immediate action. However, I strongly suggest to set them deferred so that if the installation fails. they can be rolled back.

Answer 2

Another alternative for very simple actions is a little embedded vbscript. Just the "CustomAction" and "InstallSequence" nodes needed, with the CustomAction looking like this:
<CustomAction Id="RestoreBackupDbFile" Script="vbscript" >
<![CDATA[
Set fso = CreateObject("Scripting.FileSystemObject")
path = fso.BuildPath(Session.Property("DATAFOLDER"), "Default")
if fso.FolderExists(path) then
dbp = fso.BuildPath(path, "TEST.db.bak")
if fso.FileExists(dbp) then
fso.CopyFile dbp, fso.BuildPath(path, "TEST.db"), true
fso.DeleteFile dbp
end if
end if
]]>
</CustomAction>
Note the use of Session.Property to get values from the executing MSI.