Get full qualified host name in WIX
In one of our install we need to know the full qualified computer name during installation. For that purpose I did create an custom action with a simple vbscript that simple get the computer name and domain name and create the full qualified string and set property FQDN accordingly.
<CustomAction Id="FindHostDomain" Script="vbscript" Return="check"> <![CDATA[ Dim Info Set Info = CreateObject("AdSystemInfo") Dim InfoNT Set InfoNT = CreateObject("WinNTSystemInfo") Session.Property("FQDN") = lcase(InfoNT.ComputerName & "." & Info.DomainDNSName) ]]> </CustomAction> |
To execute this script and set FQDN so we can use it in our component’s add this to the install execution sequence.
<InstallExecuteSequence> <Custom Action="FindHostDomain" Before="CostInitialize" >Not Installed</Custom> </InstallExecuteSequence> |
HowTo add new key to appsettings with WIX
When adding a new key for appsettings you need to split the action in 3 steps.
1. Create the new empty “add” element
2. Create and set the “key” attribute. The tricky part here is how to add the “key” to new created “add” element from step one. One way is to assume that the new created “add” element is the only element without a “key” attribute
3. Create and set the “value” attribute.
<util:XmlFile Id='conf1' Action="createElement" ElementPath="//configuration/appSettings" Name="add" File="[INSTALLDIR]Web.config" Sequence="1" /> <util:XmlFile Id='conf2' Action="setValue" ElementPath="//configuration/appSettings/add[\[]not(@key)[\]]" Name="key" Value="NewConfig" File="[INSTALLDIR]Web.config" Sequence="2" /> <util:XmlFile Id='conf3' Action="setValue" ElementPath="//configuration/appSettings/add[\[]@key='NewConfig'[\]]" Name="value" Value="the new value" File="[INSTALLDIR]Web.config" Sequence="3" /> |
HowTo to set appsettings during installation using WIX
The point where most people have a hard time is remembering is to escape brackets. This to ensure WIX will not think it a property. If you forget to-do this you may end up in a situation where “config2” value will bet set on “config1” instead. See a correct example bellow
[ should be [\[]
] =should be [\]]
<Component Id='UpdateConfig' Guid='A89D47AF-7DBE-4a8d-9848-F35C78FD95ED' DiskId='1' KeyPath="yes"> <util:XmlFile Id='config1' Action="setValue" ElementPath="//configuration/appSettings/add[\[]@key='FirstKey'[\]]/@value" File="[INSTALLDIR]Web.config" Value="[NEWVALUE1]" /> <util:XmlFile Id='config2' Action="setValue" ElementPath="//configuration/appSettings/add[\[@key='SecondKey'[\]]/@value" File="[INSTALLDIR]Web.config" Value="[NEWVALUE2]" /> </Component> |
And the example web.config
<?xml version="1.0"?> <configuration> <appSettings> <add key="FirstKey" value="oldvalue"/> <add key="SecondKey" value="oldvalue"/> </appSettings> </configuration> |
Silent or unattended installation on NAV
What is silent or unattended installation
Simply said silent install is installation without any UI. In this case it’s about how to run “setup.exe” in silent mode. It’s recommended that you only run “setup.exe” when you install a new NAV installation, because the installer have been tested by them using this procedure only. So by that said it’s no longer supported to install from the different msi files directly. This is true for all NAV 2009 releases. The major problem you may run into if you are installing directly from the msi files is that you will not get prerequisites (as .Net, Report Viewer and so on) installed and you will also miss out one some pre installs checks (validating that you have everything needed as outlook).
How to-do it?
It’s very simple. “setup.exe” does support some different parameters for this purpose:
/quiet <– will turn of the UI
/log [filename] <– create a log text file in the specified location
/config [filename]<– point to the configuration file to use during the installation
/uninstall <– will simple un install the product
/repair <– repairs a bad installation
How do you define a good installer?
Did read Christopher Painter blog “Back To Basics – Installation Principles” today. It contain some very basic rules of creating an installer. In his blog he lists 14 point of what to avoid and what you installer should do to be a good installer? I have personally seen big problem rise from his advice number 12 about using standard installation part and avoid using you home maid as much as possible. So to make it short, I think every installer developer should really look into this list to avoid doing the same mistakes.
And here is the list copied from Christopher.
1) Remember that your install is the very first impression the user gets of your application. If your install sucks or worse fails that will not want to use your software or your support desk will get flooded with calls. I can not understate this point. I have saved companies from the brink of bankruptcy by fixing their deployment problems and I’ve seen companies fail that were unwilling to take their problems seriously.
The pain of .NET “AnyCPU” build typ for installers
Today I found an interesting post about why we should avoid using “AnyCPU” as build type when we are building managed assemblies. The problem simple is that when installing the application and are writing registrie key we need to define if it’s a 32 bit or 64 bit application in the MSI. You can build an EXE as “AnyCPU” and on an x86 windows machine it will run on the 32bit CLR and on an x64 windows machine it will run as a 64bit process.
Christopher Painter gives this example on his blog post to explain the problem:
So let’s start with a simple example. Let’s go back 10 years in time and pretend we are writing an x86 application and x86 installer with no concern for x64. Someone hands you a vb6 EXE and a regfile ( HKLM\SOFTWARE\Company\Product type entries ) and says this is what needs to be deployed. You go off and create an MSI that writes the registry values, deploys the EXE and creates a shortcut. Now let’s come back to present. You take that MSI and throw it on a modern Windows 7 x64 box and it works just fine.
But now let’s pretend that the EXE was a .NET application. If it was compiled as x86 it would behave the same way. But if that application was built at AnyCPU ( the default for all versions of Visual Studio prior to VS2010 ) we are going to land in one of those traps. Here’s why:
MSI is marked as an x86 package so it writes the registry data to the Wow6432Node of the registry so the expected x86 application can find it. While the EXE gets installed to ProgramFiles(x86) it will actually JIT as a 64 bit process. This process will fail to find it’s registry resource at runtime and crash. This is because the .NET BCL Win32.Registry class cares about bitness.
You can find his complete post here