I am installing some certificates into localStore and for some strange reason all those certs are suffixed with "_wixCert_0" or "_wixCert_1". I've tried to manually remove all the certificates prior install to make sure that there's nothing left, but it still happens. What could be the reason?
This is how i've defined the certificates:
<Component Id="MyCert_file" Guid="*">
<File Id="MyCert" Name="MyCert.crt" Source="$(var.CertSourceDir)\MyCert.crt" />
</Component>
<Component Id="MyCert" Guid="..." KeyPath="yes">
<iis:Certificate Id="MyCert"
Name="MyCert"
Request="no"
StoreLocation="localMachine"
StoreName="ca"
Overwrite="yes"
BinaryKey="MyCert"
/>
</Component>
The certificates get added to the certstore, but they have friendly name like "MyCert_wixCerts_0" and so on. I cannot figure it out why is it happening.
Anyone else does?
In the WiX source code in src\ca\serverca\scaexec\scacertexec.cpp the InstallCertificatePackage method adds "wixCert" and an increasing unique number to the certificate name before installing it. It looks to be to make sure the name is unique in the certificate store.
The UninstallCertificatePacket method tries to find certificates using the CERTNAME_wixCert_ prefix to find the certificates to uninstall.
There are logging messages in the code that show the certificate names it is installing/uninstalling with the extra stuff added to the name.
Related
This is a repeat of Wix - Keeping track of installed applications, but the accepted answer just suggested that one could do something different than what was asked.
So, (in WiX) how does one make Per Machine installers for separate products from a single company with each having shortcuts under Start Menu/Programs/CompanyName/ProductName (where ProductName changes for each product) such that Start Menu/Programs/CompanyName will be removed if and only if all the products are uninstalled?
The specific names don't matter, but for discussion assume CompanyName is ExampleLLC with products named ProductA, ProductB, and ProductC. Assuming each product has a separate installer and the shortcuts are each to a file installed by the same product installer. So, call them RunA, RunB, and RunC targeted at ProductA.exe, ProductB.exe, and ProductC.exe respectively.
To be clear "Start Menu/Programs" maps to "C:\Users\All Users\Microsoft\Windows\Start Menu\Programs" under Windows 7, but other OS versions map this differently.
NOTE: The answer must work for perMachine installations and if ICE warnings must be ignored, please mention them.
This sounds trivial, but WiX and the Installer SDK emit errors or warnings at everything I've tried. They need a "key" to check if something (or collection thereof) is still present on the machine and have biases against both directories and shortcuts as keys. AND they put special requirements on items installed per user, but then don't trust that "ProgramMenuFolder" is NOT per user for a "perMachine" installation.
Just include the same component (with the same GUID), which installs the shortcut, into two products. MSI will count and handle installed component by itself.
Ignore ICE64 (i.e. tell light.exe to do so) and "just do it".
But use advertised shortcuts or see the question Wix create non advertised shortcut for all users / per machine.
If you do those two things the extra nesting level for "CompanyName" won't matter.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="ProductA" Language="1033" Version="1.0.0.0" Manufacturer="ExampleLLC" UpgradeCode="YOUR_GUID_HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<Media Id="1" Cabinet="Setup.cab" EmbedCab="yes" CompressionLevel="high" />
<Property Id="DISABLEADVTSHORTCUTS" Value="1" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramMenuFolder">
<Directory Id="MyStartMenuCompanyFolder" Name="ExampleLLC">
<Directory Id="MyStartMenuProductFolder" Name="ProductA" />
</Directory>
</Directory>
<Directory Id="ProgramFilesFolder">
<Directory Id="MyProgramFilesCompanyFolder" Name="ExampleLLC">
<Directory Id="MyProgramFilesProductFolder" Name="ProductA">
<Component Id="ProductA.exe">
<File Source="../ProductA/bin/$(var.Configuration)/ProductA.exe" KeyPath="yes">
<Shortcut Id="RunA" Name="RunA" Directory="MyStartMenuProductFolder" Advertise="yes"/>
</File>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
<Feature Id="Complete" Level="1">
<ComponentRef Id="ProductA.exe" />
</Feature>
</Product>
</Wix>
Produces 2 instances of ICE error 64 complaining that each directory (MyStartMenuProductFolder and MyStartMenuCompanyFolder) "is in the user profile but is not listed in the RemoveFile table".
If one makes a duplicate WiX file substituting ProductB for ProductA (and RunB for RunA), then ignoring this error produces installers that do just what they should.
So don't trust ICE64's implication that something won't get removed on uninstall. Ignore the error and just test your installer.
NOTE: This error has nothing to do with having an extra directory level, but in trying to dodge it AND fighting with ICE43 and ICE57 that pop up if you try to use a non-advertised shortcut led me "down a rabbit hole" involving using the inner directory (MyStartMenuProductFolder) as a KeyPath for a component including just the RunA shortcut. Which worked fine, but left the ICE64 warning for the outer directory (MyStartMenuCompanyFolder).
I try to execute an EXE file from an MSI file in WiX, but I got 1603 error when doing InitializeSetup.
Action ended 12:09:54: InstallValidate. Return value 1.
Action start 12:09:54: InstallInitialize.
Action ended 12:09:54: InstallInitialize. Return value 3.
Action ended 12:09:54: INSTALL. Return value 3.
What is wrong in this WiX Script?
<Product Name='something' Id='11934d63-12d1-4792-829e-046de3bb987e'
UpgradeCode='{a101616a-365c-44a7-bfcb-fafb356c2ea1}'
Language='1033' Version='8.3.4' Manufacturer='something2'>
<Package Id='*' InstallerVersion='200' Compressed='yes' />
<Binary Id="Instalator.exe" SourceFile="d:\Instalator.exe"/>
<CustomAction Id="LaunchFile" BinaryKey="Instalator.exe" ExeCommand="" Execute='deferred' Return='asyncNoWait' Impersonate='no'/>
<InstallExecuteSequence>
<Custom Action='LaunchFile' Before='InstallFinalize'/>
</InstallExecuteSequence>
</Product>
I don't know why, but when I add:
<Directory Id='TARGETDIR' Name='SourceDir'>
<Component Id='MainExecutable' Guid='1193cd63-12d1-4792-829e-046de3bb987e'>
</Component>
</Directory>
<Feature Id='Complete' Level='1'>
<ComponentRef Id='MainExecutable' />
</Feature>
after Package node -> then it works fine. I need to figure out why...
I have some other concerns about what you are doing here, but if you really need to go out of process to an EXE to complete your install, then I'd suggest using the Quiet Execution Custom Action.
You should know though that this isn't a good practice for a number of reasons. 1) It's not declarative, 2) it doesn't support rollbacks. There are others but those are the biggest IMO.
BTW, WiX isn't "scripting". Understand that and you'll understand why not to call EXE's.
Because you are running the exe as a deferred action, it runs in the context of the SYSTEM account. This error is due to the system account not having the required permissions on the file system http://support.microsoft.com/kb/834484.
It is possible to get around this using PowerShell to execute the exe using the -RunAs switch, but this is a bit nasty. It really all depends exactly what you are doing in the exe as to the best course of action. I'm with Mr. Painter, using an EXE should be the last resort.
Another option is to move the exe setup code so that it runs the first time the user runs the app.
Important note for WIX, After completion of all application installation then the .sql file or database files runs through wix or wpf or winform application.
We have an installer created using WIX. As part of this install we would like to show the currently selected installation path. I thought this would be much easier than it is, apparently. I have tried using the a public property "INSTALLDIR" (I know we're not using Installshield, this value is a directory ID.)
<Directory Id="INSTALLDIR" Name="AcmeInc">
I can also see where INSTALLDIR gets set when running the install
MSI(EC:6C) Dir (target): Key: INSTALLDIR , Object: C:\Program Files\AcmeInc\
but when I try to show this on the UI using a Text attribute I get "...\." which doesn't even look to be a relative path.
I know there has got to be something simple I'm missing here.
Assuming you're using WiX 3.5 and the MajorUpgrade element - the following should work (I usually use APPLICATIONFOLDER instead of INSTALLDIR - but they should be interchangeable).
First, let's set ARPINSTALLOCATION as described on http://robmensching.com/blog/posts/2011/1/14/ARPINSTALLLOCATION-and-how-to-set-it-with-the-WiX-toolset
<SetProperty Id="ARPINSTALLLOCATION" Value="[INSTALLDIR]" After="CostFinalize" />
Now lets set the selected installation folder to the previous installation folder, if one previously existed that is.
<Property Id="INSTALLDIR" Secure="yes">
<RegistrySearch Id="FindInstallLocation"
Root="HKLM"
Key="Software\Microsoft\Windows\CurrentVersion\Uninstall\[WIX_UPGRADE_DETECTED]"
Name="InstallLocation"
Type="raw"
Win64="yes" />
</Property>
And during the UI sequence, we want this value to be set 'early'
<InstallUISequence>
<AppSearch After="FindRelatedProducts"/>
</InstallUISequence>
I have a component I need to install only if a registry key exists which means an application has been installed.
I need to assign the value of the registry key (it is a directory) to a property then use this property to copy files from.
I have the following script so far but get an error "The system cannot find the file '[MYTESTDIR]fileToCopy.dat'."
Any help would really be appreciated.
<Property Id="MYTESTDIR">
<RegistrySearch Id="NetFramework20"
Root="HKLM"
Key="SOFTWARE\TEST\VALUE\1.00"
Name="MyName"
Type="directory" />
</Property>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="TEST" Name="Test">
<Component Id="MyComponent" Guid="E5FF53DE-1739-42c4-BE37-60F810C9CD69">
<Condition>MYTESTDIR</Condition>
<File Id="fileToCopy.dat" Name="fileToCopy.dat" Source="[MYTESTDIR]fileToCopy.dat">
<CopyFile Id="fileToCopy.datCopy" DestinationProperty="WEBSERVICEBINFOLDER" />
</File>
</Directory>
</Directory>
</Directory>
<Feature Id="MyFeature" Title="MyFeature" Level="1">
<ComponentRef Id="MyComponent" />
</Feature>
Based on my reading of the Wix Schema documentation, your problem is that you have the CopyFile element nested under a File element. Ditch the File element and just have the CopyFile sit under the Component:
<Component Id="MyComponent" Guid="E5FF53DE-1739-42c4-BE37-60F810C9CD69">
<Condition>MYTESTDIR</Condition>
<CopyFile Id="fileToCopy.datCopy" SourceName="[MYTESTDIR]fileToCopy.dat" DestinationProperty="WEBSERVICEBINFOLDER" />
</Component>
The way you had it, nested under the File, Wix was looking for the file on your system during the build - rather than setting up a copy command to be run at install time.
MYTESTDIR is a windows installer property which will get its value on the target system when the package is being installed.
However, you are trying to use this property in a Source attribute, which is used to point to files on the system where the setup package is being build.
Obviously that is not going to work. Windows installer properties don't even exist while the Source attribute is being evaluated, so Source can definitely not support such use.
Bryan's answer is the correct solution for what you're trying to do here. Using CopyFile under a File element is not illegal, but it is intended for copying files which you also install. In this case, you want to copy a file which is already on the target system, so the File element is not appropriate.
Please, can someone provide me with a WiX snippet or solution for the mentioned scenario. I need to include the pfx file in the WiX msi and the user will download my msi to his machine via the internet explorer and Click install and I need also the certificate to be installed on his machine.
You need the Certificate element. It is part of the IIS extension for wix, but can be used for non-IIS related installations also.
You need to
declare a prefix for the iis namespace, for
example like this in the root Wix element:
<Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'
xmlns:iis='http://schemas.microsoft.com/wix/IIsExtension'>
Embed the PFX file as a binary
stream in your install package. Add
a Binary element under the
product element like this:
<Binary Id="MyCertificateBinaryStream"
SourceFile="c:/path/to/mycertificate.pfx" />
Declare a component with a <iis:Certificate> element, for
example like this. Look at the
documentation, you need to fill in some
more attributes. Note that you don't need CertficatePath if you use the BinaryKey attribute.
<Component Id="MyCertificateComponent" Guid="MY-GUID-HERE">
<iis:Certificate Id="MyCertificate"
BinaryKey="MyCertificateBinaryStream"
... some more attributes ...
/>
</Component>
Activate the IIS extension by adding
the option -ext WixIISExtension
option when invoking the wix command line tools. If you use visual studio, this is just a matter of adding a reference in your wix project to WixIISExtension.
To expand on the answer a little, the following set of attributes worked for me:
<iis:Certificate
Id="My.Certificate"
StoreName="root"
Overwrite="yes"
Name="My Friendly Certificate Name"
Request="no"
BinaryKey="MyCertificate.Binary"
StoreLocation="localMachine" />
Where the <Product> element contained a <Binary> child as follows:
<Binary
Id="MyCertificate.Binary"
SourceFile="$(var.ProjectDir)MyCertificate.pfx" />
(I included the PFX file within my WiX project).