The tutorial gave a relatively simple action to check a
product key on install. For my own project I would like to ask the user to
specify a remote service uri, check that the uri format is okay, warn the user if it is not, and finally write the value
to my application’s configuration file.
First of all, my installer had no user interface at all, so
I added the WixUI_FeatureTree as I described in a previous post. As in my
tutorial, I am going to add the new custom action code by right-clicking the
solution and doing Add > New Project and selecting Windows Installer XML
> C# Custom Action Project and I will name it CustomInstallActions.
The custom action
will read in what the user input as SERVICEURI and will output a URIACCEPTED
value to the install session. For right
now I am simply testing whether the string that is passed in can be used to
form a URI. The CustomAction attribute
decorating the class indicates the method is an entry point for the installer
custom action.
public class CheckUriAction
{
///
/// Checks that user input is a well-formed URI.
///
/// The installation session.
///
///
/// The . This will always be success so
/// long as the evaluation can be made. It does not indicate
/// whether the URI is well-formed or not.
///
[CustomAction]
public static ActionResult CheckUri(Session session)
{
// log that custom action is being called.
session.Log("Checking user input URI");
// get the user string input from the install session
var uri = session["SERVICEURI"];
// check that the string passed in can be used to construct a valid URI
var isURI = Uri.IsWellFormedUriString(uri, UriKind.Absolute);
// write the evaluation back to the installation session
session["URIACCEPTED"] = isURI ? "1" : "0";
// return succes. This allows the installation to continue and the
// user will be able to change the input if necessary. A different
// ActionResult would cause the installation to end.
return ActionResult.Success;
}
To my Product.wxs WiX file I add a Fragment to reference this custom action and the dll that contains it. As I explained in a previous post, the C# custom action gets wrapped by [someEXE] into a managed custom action. This is handled automatically if you use the WiX C# CustomAction project, so the actual dll we reference is the wrapped one that has the .CA.dll extension.
<Fragment>
<CustomAction Id='CheckingUri' BinaryKey='CheckUri.CA' DllEntry='CheckUri' />
<Binary Id='CheckUri.CA' SourceFile='..\..\..\CheckURIAction\bin\Debug\CustomInstallActions.CA.dll' />
</Fragment>
The DllEntry attribute of the CustomAction is the name of
the method that we designated as the entry point in our class. The Id of the
CustomAction element is what we will use to reference this in our installation
UI.
This UI is a new dialog I add to the WiX project that will
ask for the user’s input. By
right-clicking on the WiX project and selecting Add > New Item > WiX >
WiX File I’m given the skeleton of a WiX fragment. To this I add a UI component
and within that a Dialog I will call ServiceDlg. If you followed the WiX
tutorial you’ve done this. The key controls to look at are the “NameEdit” Edit
control and its property called SERVICEURL and the “Next” PushButton control.
When the user pushes the Next button it will “Publish” the CheckingUri action
we specified in the fragment above. The value of SERVICEURL will be passed
through the session to the action. In turn the action adds the URIACCEPTED
property to the session, which we evealute to determine which dialog to show to
the user. In the case there the URI is not accepted, we show the InvalidURIDlg
that we will add below. If everything is ok we allow the user to move on to the
CustomizeDlg dialog which is already built in to the WixUI_FeatureTree set.
<Dialog Id="ServiceDlg" Width="370" Height="270" Title="[ProductName] Setup" NoMinimize="yes">
<Control Id="ServiceLabel" Type="Text" X="45" Y="73" Width="100" Height="15" TabSkip="no" Text="&EED Service Address:" />
<Control Id="NameEdit" Type="Edit" X="45" Y="85" Width="220" Height="18" Property="SERVICEURI" Text="{80}" />
<Control Id="Back" Type="PushButton" X="180" Y="243" Width="56" Height="17" Text="&Back">
<Publish Event="NewDialog" Value="LicenseAgreementDlg">1</Publish>
</Control>
<Control Id="Next" Type="PushButton" X="236" Y="243" Width="56" Height="17" Default="yes" Text="&Next">
<Publish Event="DoAction" Value="CheckingUri">1</Publish>
<Publish Event="SpawnDialog" Value="InvalidURIDlg">URIACCEPTED = "0"</Publish>
<Publish Event="NewDialog" Value="CustomizeDlg">URIACCEPTED = "1"</Publish>
</Control>
<Control Id="Cancel" Type="PushButton" X="304" Y="243" Width="56" Height="17" Cancel="yes" Text="Cancel">
<Publish Event="SpawnDialog" Value="CancelDlg">1</Publish>
</Control>
<Control Id="BannerBitmap" Type="Bitmap" X="0" Y="0" Width="370" Height="44" TabSkip="no" Text="WixUI_Bmp_Banner" />
<Control Id="Description" Type="Text" X="25" Y="23" Width="280" Height="15" Transparent="yes" NoPrefix="yes">
<Text>[ProductName] needs access to the DVS Core Service</Text>
</Control>
<Control Id="BottomLine" Type="Line" X="0" Y="234" Width="370" Height="0" />
<Control Id="Title" Type="Text" X="15" Y="6" Width="200" Height="15" Transparent="yes" NoPrefix="yes">
<Text>{\WixUI_Font_Title}Core Service Configuration</Text>
</Control>
<Control Id="BannerLine" Type="Line" X="0" Y="44" Width="370" Height="0" />
</Dialog>
I add the InvalidURIDlg to this same UI element in my
ServiceDlg.wxs since they go hand-in-hand. This dialog is created from the
SpawnDialog event in the ServiceDlg dialog, so it has that dialog as a parent.
The dialog displays a message to the user and then the user’s one option is to
click a button to make the dialog go away (and return back to the ServiceDlg).
<Dialog Id="InvalidURIDlg" Width="260" Height="85" Title="[ProductName] [Setup]" NoMinimize="yes">
<Control Id="Return" Type="PushButton" X="100" Y="57" Width="56" Height="17" Default="yes" Cancel="yes" Text="&Return">
<Publish Event="EndDialog" Value="Return">1</Publish>
</Control>
<Control Id="Text" Type="Text" X="48" Y="15" Width="194" Height="30" TabSkip="no">
<Text>The service location provided is not a valid URI.</Text>
</Control>
</Dialog>
The final thing I need to do show this dialog is fit this
new dialog into the install sequence. I
add the dialog reference to the same Fragment where I reference the FeatureTree
set. Then I add the events to insert the ServiceDlg between the
LicenseAgreementDlg and CustomizeDlg of the FeatureTree set.
<Fragment>
<UI Id="MyWixUI_FeatureTree">
<UIRef Id="WixUI_FeatureTree" />
<UIRef Id="WixUI_ErrorProgressText" />
<DialogRef Id="ServiceDlg" />
<Publish Dialog="LicenseAgreementDlg" Control="Next" Event="NewDialog" Value="ServiceDlg" Order="2">LicenseAccepted = "1"</Publish>
<Publish Dialog="CustomizeDlg" Control="Back" Event="NewDialog" Value="ServiceDlg" Order="2">1</Publish>
</UI>
</Fragment>
You can run the install as it is and see the custom action “in
action” but at this point it isn’t particularly useful unless we do something
with the value that the user input. My goal is to write this value to the
App.config of my application as the address for a service endpoint. Initially I
just want to try to write the name to the appSettings element of the
App.config. This is really quite simple with WiX using the XmlFile utility
extension.
First we need a reference from the WiX project to the
WixUtilExtension library. With that reference in place WiX will handle the correct
commands to compile the library in with our installer. So to our main Wix root
element we need to add the XML namespace for util.
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
Then to the same component that contains the configuration
file that we want to change we add a series of XmlFile elements. The first will
create a new node “add” to the appSettings node in our config file. Note that
the configuration must have an appSettings node to begin with, AND even if the
node is empty it must have separate opening and close tags.
will not work; you need to have under
the configuration element. The second element will add a “key” attribute to the
“add” element and give it a value of “ServiceUri”. The final element will give
a “value” attribute to our element with the value of the SERVICEURI that was
passed in from the user. The INSTALLFOLDER in the file references the directory
I gave the Id of INSTALLFOLDER which is the main install folder for the
application.
<File Id="File.ElectionDataService.Config" Name="ElectionService.exe.config" Source="$(var.ServicePath)\ElectionService.exe.config"/>
<util:XmlFile Id='Settings.ElectionService.Config1' File='[INSTALLFOLDER]ElectionService.exe.config'
Action='createElement' Name='add' ElementPath='//configuration/appSettings' Sequence='1' />
<util:XmlFile Id='Settings.ElectionService.Config2' File='[INSTALLFOLDER]ElectionService.exe.config'
Action='setValue' Name='key' Value='ServiceUri' ElementPath='//configuration/appSettings/add' Sequence='2' />
<util:XmlFile Id='Settings.ElectionService.Config3' File='[INSTALLFOLDER]ElectionService.exe.config'
Action='setValue' Name='value' Value='[SERVICEURI]' ElementPath='//configuration/appSettings/add' Sequence='3' />
Running the installation now results in the following
appSettings block in the configuration file:
Simply writing to the appSettings is okay, but what I really
want to do is save the user input in the configuration as the endpoint for a
service that the application needs. To do this I need to refine where the
XmlFile elements write to. My config file already has the endpoint element that
I need; I just want to fill in the address attribute. Before installation it looks
like this:
<endpoint binding="wsHttpBinding" bindingConfiguration="wsHttpBindingNoSec"
contract="ICoordinateInterface" name="WSHttpBinding_ICoordinateInterface">
I really only need a single XmlFile element in my Wix file
that will add the address attribute to that endpoint node with a value of
whatever the user entered. Another consideration is that I actually have
multiple endpoints for different services in the configuration file, so I need
to select the endpoint with the service interface that corresponds to the one I
want to change. I replace the sequence of XmlFile elements above with a new
one.
<File Id="File.ElectionDataService.Config" Name="DVS.EMS.Services.ElectionData.ElectionDataService.exe.config" Source="$(var.ServicePath)\DVS.EMS.Services.ElectionData.ElectionDataService.exe.config"/>
<util:XmlFile Id='Settings.ElectionDataService.Config' File='[INSTALLFOLDER]DVS.EMS.Services.ElectionData.ElectionDataService.exe.config'
Action='setValue' Name='address' Value='[SERVICEURI]' ElementPath='//configuration/system.serviceModel/client/endpoint[\[]@contract="ICoordinateInterface"[\]]' Sequence='1' />
The bracketed @contract=… attribute in the ElementPath picks
out the individual endpoint element with the service interface that I want to
change, but not the others. The brackets need to be escaped with the pattern shown.
Now running the install my configuration ends up with the
following endpoint:
