I have a Windows app which has 2 versions, kind of, but a different name for each version. I use the same .wxs to build because I have no reasons to create a second wix project. I do not want to argue wether it is a good idea in here.
The thing is: each version must be installed in
path \ mainDir \ versionDir
Where path \ mainDir is the same for each version.
My problem is that mainDir is being entirely overwritten on install by each version.
Let's say I install version1, I'll have
path \ mainDir \ version1Dir
And then if I install version2, instead of having
path \ mainDir \ version1Dir
path \ mainDir \ version2Dir
I'll have
path \ mainDir \ version2Dir
I've been trying to get this around using Wix - how to prevent overwrite entire directory?, but it only applies to files since Conditions cannot be assigned to directories (or maybe I have haven't found how to do so, I don't know).
My goal is to have each versions able to install in its own directory, creating mainDir if it doesn't exist, but only removing it if it's empty.
Here's the code, any leads would be very much appreciated.
<!-- This is in Product, I'm just pasting it here -->
<Property Id="ALREADYINSTALLED">
<RegistrySearch Id="InstallPath" Key="Software\$(var.MainDir)" Name="MainFolder" Root="HKCU" Type="directory" />
</Property>
<Property Id="SECONDALREADYINSTALLED">
<RegistrySearch Id="SecondInstallPath" Key="Software\$(var.MainDir)\$(var.SecondDir)" Name="SecondFolder" Root="HKCU" Type="directory" />
</Property>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="WINDOWSVOLUME">
<Directory Id="INSTALLFOLDER" Name=".">
<Directory Id="MAINFOLDER" Name="$(var.MainDir)">
<!-- Allows the removal of this directory on uninstall -->
<Component Id="mainFolderRemoval">
<RegistryValue Root="HKCU" Key="Software\$(var.MainDir)" Name="MainFolder" Type="string" KeyPath="yes" />
<RemoveFolder Id="removal" On="uninstall" Property="ALREADYINSTALLED"/>
</Component>
<Directory Id="SECONDFOLDER" Name="$(var.SecondDir)">
<Component Id="secondFolderRemoval">
<RegistryValue Root="HKCU" Key="Software\$(var.MainDir)\$(var.SecondDir)" Name="SecondFolder" Type="string" KeyPath="yes" />
<util:RemoveFolderEx On="uninstall" Property="SECONDALREADYINSTALLED"/>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
</Directory>
<SetDirectory Id="WINDOWSVOLUME" Value="[WindowsVolume]" />
<!-- Overwrites the main folder if already installed -->
<SetDirectory Id="MAINFOLDER" Value="[ALREADYINSTALLED]"> <![CDATA[ALREADYINSTALLED]]> </SetDirectory>
</Fragment>
So I ended up finding why it wouldn't work.
You have to make sure that your product upgrade code is different for each version, which was quite obvious actually.
One could argue that I should delete this post, but I believe it could happen to anyone and this is too much of a stupid issue to let people loose time with this. I'll leave this question as an example, hopefully it might be useful to somebody in the future.
Related
We execute the following command line with heat (3.0.5210.0):
heat.exe -srd -suid file OurLib.dll -out bin_OurLib.tmp
OurLib.dll is a VC++ 2008 dll file, it's a COM component.
Output (bin_OurLib.tmp)
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<DirectoryRef Id="TARGETDIR">
<Component Id="OurLib.dll" Guid="PUT-GUID-HERE">
<File Id="OurLib.dll" KeyPath="yes" Source="SourceDir\OurLib.dll">
<Class Id="{B1AB297C-1BC6-65E1-A7C1-A1833DFAED6A}" Context="InprocServer32" Description="OurProduct.OurLib">
<ProgId Id="OurProduct.OurLib" Description="OurProduct.OurLib" />
</Class>
</File>
</Component>
</DirectoryRef>
</Fragment>
</Wix>
This works fine.
Now we updated the VS to 2015, and compiled OurLib with it.
Running the same heat command now results in different output:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<DirectoryRef Id="TARGETDIR">
<Component Id="OurLib.dll" Guid="PUT-GUID-HERE">
<Class Id="{B1AB297C-1BC6-65E1-A7C1-A1833DFAED6A}" Context="InprocServer32" Description="OurProduct.OurLib">
<ProgId Id="OurProduct.OurLib" Description="OurProduct.OurLib" />
</Class>
<File Id="OurLib.dll" KeyPath="yes" Source="SourceDir\OurLib.dll" />
<RegistryValue Root="HKCR" Key="CLSID\{B1AB297C-1BC6-65E1-A7C1-A1833DFAED6A}\InProcServer32" Value=""[#OurLib.dll]"" Type="string" Action="write" />
</Component>
</DirectoryRef>
</Fragment>
</Wix>
And when wix is linking, it gives error:
error LGHT0130 : The primary key 'reg51A1FC16367511AF81E9B18CA009A1C6' is duplicated in table 'Registry'. Please remove one of the entries or rename a part of the primary key to avoid the collision.
Checking the wixobj file, reg51A1FC16367511AF81E9B18CA009A1C6 is related to line
<Class Id="{B1AB297C-1BC6-65E1-A7C1-A1833DFAED6A}...." and <RegistryValue Root="HKCR" Key="CLSID\{B1AB.... - obviously.
Anwyay, this is obviously due to the generated wix output files are different.
Why is that if compiling a dll with a newer C++ compiler will cause WIX HEAT to generate different output, while running the same options, etc.
And how can I have back the same "old" output, which we need.
Tried with -scom and -sreg, none of them gave back the "old" output.
Well primary key duplicated means you've got that same RegistryValue in two different places in your wix source code somehow.
Or maybe the newer DLL is self-registering differently? It's putting the InProcServer32 value in quotes. I don't think that's normal.
Or have you checked that your 2008 and 2015 DLL source and project files are identical? The VS project upgrade process changes things...
I have a problem with WiX and C++ custom actions DLL: I want to get the installation location specified in the .wxs file from custom action dll, I am using WcaGetTargetPath, but this API doesn't work. Anyone any idea how to do achieve this?
WiX file:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="$(var.PlatformProgramFilesFolder)" Name="PFiles">
<Directory Id="CompanyDir" Name="ABC">
<Directory Id="PCMINSTALLDIR" Name="ClientMonitor">
<Directory Id="STDSCIPTSDIR" Name="standard_scripts">
</Directory>
<Directory Id="CSTMSCIPTSDIR" Name="custom_scripts">
</Directory>
</Directory>
</Directory>
</Directory>
</Directory>
.....
<CustomAction Id="ChangeConfig"
BinaryKey="PcmConfig"
DllEntry="ModifyConfigFile"
Execute="deferred"
Return="check"
Impersonate="no"
HideTarget="no" />
<InstallExecuteSequence>
<Custom Action="ChangeConfig" Before="InstallFinalize" />
</InstallExecuteSequence>
Custom Action method:
LPWSTR pwzTargetPath = NULL;
hr = WcaGetTargetPath(L"PCMINSTALLDIR", &pwzTargetPath);
ExitOnFailure(hr, "Failed to get the PCM installation path.");
I have a tests folder in one of my modules, with 3 subfolders:
Model
Helper
Integration
running
phpunit --group My_Module
executes only the tests in Model and Helper directories, with the Integration folder left untouched. Test files reside directly in the folder in all of the cases, so I'm not sure what's causing the problem.
Here's my phpunit.xml:
<?xml version="1.0"?>
<!-- initial phpunit configuration file, that you can modify for your project needs -->
<phpunit cacheTokens="true"
colors="true"
convertErrorsToExceptions="true"
convertNoticesToExceptions="true"
convertWarningsToExceptions="true"
stopOnError="false"
stopOnFailure="false"
stopOnIncomplete="false"
stopOnSkipped="false"
strict="false"
verbose="false"
bootstrap="app/code/community/EcomDev/PHPUnit/bootstrap.php">
<listeners>
<listener file="app/code/community/EcomDev/PHPUnit/Test/Listener.php" class="EcomDev_PHPUnit_Test_Listener" />
</listeners>
<testsuites>
<testsuite name="MyApp">
<directory suffix=".php">app/code/local/*/*/Test/*/</directory>
</testsuite>
<testsuite name="Magento Test Suite">
<file>app/code/community/EcomDev/PHPUnit/Test/Suite.php</file>
</testsuite>
</testsuites>
<filter>
<blacklist>
<!-- Exclude Magento Core files from code coverage -->
<directory suffix=".php">app/code/core</directory>
<!-- Exclude EcomDev_PHPUnit classes from code coverage -->
<directory suffix=".php">app/code/community/EcomDev/PHPUnit</directory>
<directory suffix=".php">lib/EcomDev/Utils</directory>
<directory suffix=".php">lib/EcomDev/PHPUnit</directory>
<directory suffix=".php">lib/Spyc</directory>
<directory suffix=".php">lib/vfsStream</directory>
<!-- Exclude Mage.php file from code coverage -->
<file>app/Mage.php</file>
<!-- Exclude template files -->
<directory suffix=".phtml">app/design</directory>
<!-- Exclude Varien & Zend libraries -->
<directory suffix=".php">lib/Varien</directory>
<directory suffix=".php">lib/Zend</directory>
</blacklist>
</filter>
<logging>
<!-- Uncomment this line if you want to have coverage report generated every test run
<log type="coverage-html" target="var/phpunit/coverage" charset="UTF-8"
yui="true" highlight="false"
lowUpperBound="35" highLowerBound="70"/>
<log type="coverage-clover" target="var/phpunit/coverage.xml"/>
-->
<log type="junit" target="../build/logs/junit.xml" logIncompleteSkipped="false"/>
</logging>
</phpunit>
The version of PHPunit I'm running on ubuntu VM is 3.7.28. How can I get all of the tests to run? Help would be much appreciated.
Try to call
phpunit --list-groups
This show you list of available test groups. Do you see My_Module in list?
1) Yes - issue in tests folders/structure.
2) No - issue in xml configuration.
Hello all my fellow WiX'ers,
I was wondering if it possible, and if so where I can go to learn how to do it, to run heat on a directory and have each directory inside that one be it's own Component Group.
Example:
Root Directory
Sub Dir 1
Sub Sub Dir 1
Sub Sub Dir 2
Sub Sub Dir 3
Sub Dir 2
Sub Sub Dir 1
Sub Sub Dir 2
Sub Sub Dir 3
Sub Dir 3
Sub Sub Dir 1
Sub Sub Dir 2
Sub Sub Dir 3
Then run a heat command in the Build Event of the VS2010 project (example below):
heat dir "Root Directory" -gg -sfrag -srd -dr INSTALLFOLDER -out MyWXS.wxs
and then have that WXS file structured like so:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<DirecotryRef Id="INSTALLFOLDER">
<Directory Id="dir84156489" Name="Sub Dir 1"> ... </Directory>
<Directory Id="dir84156489" Name="Sub Dir 2"> ... </Directory>
<Directory Id="dir84156489" Name="Sub Dir 3"> ... </Directory>
</DirectoryRed>
</Fragment>
<Fragment>
<ComponentGroup Id="Sub Dir 1"> ... </ComponentGroup>
<ComponentGroup Id="Sub Dir 2"> ... </ComponentGroup>
<ComponentGroup Id="Sub Dir 3"> ... </ComponentGroup>
</Fragment>
</wix>
If there is any confusion in my question or if anyone has any additional questions for me please let me know. Thank you and I look forward to hearing from you.
EDIT
Using the following xslt file I am getting the WXS structure that follows after:
**XLST File**
<?xml version="1.0" encoding="utf-8"?>
**WXS File Result**
<Wix>
<Fragment>
<DirectoryRef Id="INSTALLFOLDER">
<Directory Id="dir846546" Name="SubDir1"> ... </Directory>
<Directory Id="dir846546" Name="SubDir2"> ... </Directory>
<Directory Id="dir846546" Name="SubDir3"> ... </Directory>
</DirectoryRef>
</Fragment>
<wix:Fragment xmlns:wix="http://schemas.microsoft.com/wix/2006/wi">
<wix:ComponentGroup Id="SubDur1"> ... </wix:ComponentGroup>
</wix:Fragment>
<wix:Fragment xmlns:wix="http://schemas.microsoft.com/wix/2006/wi">
<wix:ComponentGroup Id="SubDur2"> ... </wix:ComponentGroup>
</wix:Fragment>
<wix:Fragment xmlns:wix="http://schemas.microsoft.com/wix/2006/wi">
<wix:ComponentGroup Id="SubDur3"> ... </wix:ComponentGroup>
</wix:Fragment>
</Wix>
No matter what I do I cannot get the Directories to be created as component groups...
Heat can do an XSL transform before emitting its output. Just add the -t transform.xsl argument.
All that's needed is to append a few component groups to the output. Generate a component group by matching on a first-level directory and then referencing all of the descendent components.
See the XSL for my answer to a similar question.
I'm trying to use IzPack to install my program and I'd like to add Desktop Shortcuts to the installer, here is the documentation/instructions from the IzPack website.
http://izpack.org/documentation/desktop-shortcuts.html
However, the below XML files, when compiled, only create a blank screen in the installer that hangs when you try to click "Next" to go past it. Here's what the screen looks like when running on Windows 7 - 64 bit.
Here is my install.xml and shortcutSpec.xml files.
install.xml
<?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
<installation version="1.0">
<!-- The info section. -->
<info>
<appname>Application Name</appname>
<appversion>1.0</appversion>
<url>http://www.example.com/</url>
<javaversion>1.6</javaversion>
<run-privileged condition="izpack.macinstall|izpack.windowsinstall.vista|izpack.windowsinstall.7"/>
</info>
<!-- The gui preferences indication. -->
<guiprefs width="640" height="480" resizable="yes"/>
<!-- The locale section. -->
<locale>
<langpack iso3="eng"/>
</locale>
<!-- The resources section. -->
<resources>
<res id="LicencePanel.licence" src="licence.txt"/>
<res id="InfoPanel.info" src="readme.txt"/>
<res id="shortcutSpec.xml" src="shortcutSpec.xml"/>
</resources>
<native type="izpack" name="ShellLink.dll"/>
<!-- The panels section. -->
<panels>
<panel classname="HelloPanel"/>
<panel classname="InfoPanel"/>
<panel classname="LicencePanel"/>
<panel classname="TargetPanel"/>
<panel classname="ShortcutPanel"/>
<panel classname="PacksPanel"/>
<panel classname="InstallPanel"/>
<panel classname="SimpleFinishPanel"/>
</panels>
<native type="izpack" name="ShellLink.dll"/>
<!-- The packs section. -->
<packs>
<pack name="Program and Dependencies" required="yes">
<description>Program, libraries and other dependencies</description>
<file src="ExecutableJar.jar" targetdir="$INSTALL_PATH"/>
<file src="lib" targetdir="$INSTALL_PATH"/>
<file src="save" targetdir="$INSTALL_PATH"/>
<file src="HelpContents.chm" targetdir="$INSTALL_PATH"/>
<file src="icon.png" targetdir="$INSTALL_PATH"/>
<file src="application.ini" targetdir="$INSTALL_PATH"/>
<file src="readme.txt" targetdir="$INSTALL_PATH"/>
<file src="licence.txt" targetdir="$INSTALL_PATH"/>
<file src="autorun-win.bat" targetdir="$INSTALL_PATH"/>
</pack>
<pack name="Samples" required="no">
<description>Word Document Samples</description>
<file src="samples" targetdir="$INSTALL_PATH"/>
</pack>
<pack name="Templates" required="no">
<description>Word Document Templates</description>
<file src="templates" targetdir="$INSTALL_PATH"/>
</pack>
</packs>
And the shortcutSpec.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<shortcuts>
<skipIfNotSupported/>
<programGroup defaultName="AppGroupName" location="applications"/>
<shortcut
name="Application - Startup"
target="$INSTALL_PATH\autorun-win.bat"
workingDirectory="$INSTALL_PATH"
programGroup="no"
desktop="yes"
applications="yes"
startMenu="yes"
startup="yes"/>
</shortcuts>
Additional Notes:
I am getting zero compilation errors.
Without the shortcut stuff added, the installer works fine.
My program is an executable jar, to run it automatically I've created a batch script in Windows named autorun-win.bat, which is the what the desktop shortcut should be linked to.
EDIT:
I have tried this import as well as the 32-bit flavor. Neither had any effect on the above results. Any more contributions would be greatly appreciated.
<native type="izpack" name="ShellLink_x64.dll" />
Shortcut creation depends on the native support lib ShellLink.dll which only supports 32 bit systems. For 64-Bit windows you must add the following entry as well to support both flavors:
<native type="izpack" name="ShellLink_x64.dll" />
I've never used this tool, so this may be a total red hering.
In your shortcuts file you don't have a CreateForPack statement. Could that be something to do with the fault?
Although this issue is old, I have experienced this problem today on IzPack 4.3.5. Two observations are provided here.
First, the documentation at http://docs.codehaus.org/pages/viewpage.action?pageId=230398023 shows the native statements placed inside a 'natives' tag. This appears to be incorrect for the v4 release.
Second, the ShellLink_x64 DLL must be visible to the compiler. I had to add '-h ${IZPACK_HOME}' to the compiler execution line to make this happen. Sadly there seems to be no warnings if this file cannot be found, but the installer then hangs as described.
Fixing these issues fixed this problem for me.
I have experienced a case where a working izPack configuration with shortcut creation suddenly stopped putting the icon.
It turned out the icon file created under linux with convert commad was faulty, I reverted to the old icon