Is it possible to from the wix-project set the timestamp of Files?
I am thinking like:
<File Id='id1' LastModified='2015-11-26' />
or
<File Id='id1' LastModified='[Now]' />
There is no simple way using wix file element, no attribute that specify the version.
You can check all the attribute in:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/file.html
This open source project contain many useful scripts and build custom activities, the link below is for the prebuild script.
https://github.com/tfsbuildextensions/CustomActivities/tree/master/Source/Scripts
Related
I'm building a Wix installer and I need two separate versions of said installer. One that picks up the latest development build of the project and one that picks up the latest release build. Currently my fragment looks like this:
<Property Id="Program.ReleaseBuild" Value="0" />
<?define ReleaseBuild = [Program.ReleaseBuild]?>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="InstallFolder">
<Component Id="TheExe" Guid="GUID_GOES_HERE">
<?if $(var.ReleaseBuild) = 1?>
<File Id="ProjectExe" Source="(Rel Project Path)/program.exe" />
<?else?>
<File Id="ProjectExe" Source="(Dev Project Path)/program.exe" />
<?endif?>
</Component>
</ComponentGroup>
</Fragment>
And I have a transform on the msi that transforms the file after build. But the problem is that the file is picked up on compile time not install time, so both version of the installer end up having the same file contained in them. Any idea how I can conditionally grab a dev file or a rel file in the same wix project?
If you want to create installation packages based on build quality (debug versus release), you can use two product configuration and select the source based on it. This way, you can run msbuild twice, one for each configuration. I don't understand the purpose of the transform you mentioned.
So here are steps you could take to accomplish this:
Create an empty solution.
Add your wixproj to it.
Add your csproj to it.
Add a reference of the csproj to the wixproj.
Modify your File[Source] to use the project reference, this way:
<File Source="$(var.MyProject.TargetPath)" Id="ProjectExe" />
The $(var.MyProject.TargetPath) will automatically get the exe from the correct path.
Create a batch file to run the msbuild twice, one for each configuration, with the following commands:
C:\> msbuild mySolution.sln /p:Configuration=Debug
C:\> msbuild mySolution.sln /p:Configuration=Release
The result will be two installation packages, one for each configuration.
I have a WiX package that should always deliver files, but should only uninstall the files when a condition is met. The condition is that common files should not be uninstalled if another version of the product is installed (we are not supporting true upgrades, our upgrade is installing the files to a new folder that has the version of the package and installing new versions of the common files).
I realize this can be achieved by using the same GUIDs across components or using merge modules, but I also have to account for the fact that I have legacy packages from InstallShield that could be installed. Unfortunately, the designers of those packages had no idea of what was going on with installers, and they installed files to a temp directory, then copied them to a new location, so Windows Installer has no knowledge that the files are installed.
I have tried a couple different things.
Approach #1:
<Component Id="myfile.dll" Guid="{YOUR-GUID-HERE}" Transitive="yes" >
<Condition>OTHER_VERSIONS_PRESENT ~= "FALSE"</Condition>
<File Id="myfile.dll" KeyPath="yes" Source="$(var.PATH_TO_BIN_FILES)myfile.dll" />
</Component>
Approach #2:
<Component Id="myfile.dll" Guid="{YOUR_GUID_HERE}" Permanent="yes" >
<File Id="myfile.dll" KeyPath="yes" Source="$(var.PATH_TO_BIN_FILES)myfile.dll" />
</Component>
<Component Id="myfile.dll_remove" Guid="{YOUR_GUID_HERE}" Transitive="yes" >
<RemoveFile Id="myfile.dll_remove" Name="myfile.dll" On="uninstall" />
<Condition>OTHER_VERSIONS_PRESENT ~= "FALSE"></Condition>
</Component>
Additional Info
Here is my property that I am using with the custom actions and the condition:
<Property Id="OTHER_VERSIONS_PRESENT" Value="FALSE" />
Here is my scheduling of the custom action that sets the OTHER_VERSIONS_PRESENT property. I have verified that it is correctly set to true or false, based on whether another version of the product is present.
<Custom Action="FindOtherVersionsOfProduct" After="CostFinalize" />
I have also tried the above approaches with CDATA wrapped around the condition, but this also failed. Additionally, I tried changing the install sequence of when I set the property. I've tried different conditions. But nothing has worked.
Thank you in advance for any support you can give me.
Edit: Approach 1 is working, but once I change it to be
<Condition>NOT Installed OR ((REMOVE ~= "ALL") AND (OTHER_VERSIONS_PRESENT ~= "FALSE"))</Condition>
it no longer works.
My suggestion is that both of those approaches are probably incorrect. The general solution used in all cases I can think of that both packages need to install the same files to same common location. A common merge module containing those components ensures that the Windows Installer sharing works, so uninstalling one product leaves the files behind for the remaining product (because ref counting is based on component ids and just decrements the count when a product is uninstalled). In other words it all just works without transitive components or conditions.
I want to have 2 installers with common part. So I used merge module, and created 2 wix installers.
Here is what I want to achive with more details (problem described there was solved): wix installers with common component
I am using WixUI_InstallDir so user is able to choose directory where application will be installed.
When second installer is launched I want to load previously choosen installation directory.
When user does not change default path all works fine. But if INSTALLDIR was changed in first installation, then second installer adds plugin to right path but also extracts core to default path - which is wrong.
However right path (from previous installation) is shown on "Destination Folder" dialog.
Here is significant code:
<Property Id="CORE_INSTALLATION_PATH">
<RegistrySearch Id="InstallFolderRegistrySearch" Type="raw" Root="HKLM" Key="SOFTWARE\PluginCompany\Plugins" Name="InstallFolder"/>
</Property>
<SetDirectory Id="INSTALLDIR" Value="[CORE_INSTALLATION_PATH]">CORE_INSTALLATION_PATH</SetDirectory>
<DirectoryRef Id="TARGETDIR">
<Component Id="CoreRegistryEntries" Guid="{C1701385-12CA-47EF-9FB2-884139B56390}">
<RegistryKey Root="HKLM" Key="SOFTWARE\PluginCompany\Plugins" Action="createAndRemoveOnUninstall">
<RegistryValue Type="string" Name="InstallFolder" Value="[INSTALLDIR]" KeyPath="yes"/>
</RegistryKey>
</Component>
</DirectoryRef>
You can download and run full sample solution from https://github.com/bwojdyla/wixplugins/tree/04f61b89b0465311818bec1cc06371b3dced5671
In logs I found this:
MSI (c) (38:CC) [08:54:03:324]: Dir (target): Key: INSTALLDIR , Object: C:\Program Files (x86)\PluginCompanyFolder\PluginInstaller2\
MSI (c) (38:CC) [08:54:03:324]: Dir (target): Key: INSTALLDIR.751E70EB_CF76_413B_B8C8_231A31F9C946 , Object: C:\Program Files (x86)\PluginCompanyFolder\PluginInstaller\
So there are two properties INSTALLDIR and INSTALLDIR with guid.
This second property is added by merge module and updating INSTALLDIR does not change second property. That is why core components were extracted to custom location by second installer.
To disable mudularization I used SuppressModularization attribute:
<Property Id="INSTALLDIR" SuppressModularization="yes"/>
Notice SuppressModularization description at:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/property.html
Use to suppress modularization of this property identifier in merge
modules. Using this functionality is strongly discouraged; it should
only be necessary as a workaround of last resort in rare scenarios.
A couple or three things:
Make sure you have the correct registry, maybe you need a Win64 search, maybe not, depends if the data is in the native registry or the x86 WOW one.
If it's not too late, it's typically better to install shared components to a common location (such as the common files folder for your Company Name and Product Name) to avoid this kind of thing. It's perfectly ok if not all the files are in the main application folder, as long as the app doesn't care.
Do the install with a verbose log and see what the AppSearch is doing - that's where it will set (or not) that property value. That's where you'll see if the property is being set or not, and therefore whether something else is going wrong later on.
I am quite new in creating setup project using .wxs file.I am using WIX 3.9. I want to change the physical path to virtual path in .wxs file.
Currently .wsx file is using physical path like this -
<Component Id="cmp2CB74B07C01493F593A258BAE09C0B1C" Guid="08CD4620-DE67-4C7A-A97A-212AB5BA5E52">
<File Id="filCF6108D60D7B1865907043E2ABFE30DF" KeyPath="yes" Source="C:\ProjectName\Client\Bin\AjaxControlToolkit.dll" />
</Component>
I want to use virtual path something like this -
<Component Id="cmp2CB74B07C01493F593A258BAE09C0B1C" Guid="08CD4620-DE67-4C7A-A97A-212AB5BA5E52">
<File Id="filCF6108D60D7B1865907043E2ABFE30DF" KeyPath="yes" Source="~\ProjectName\Client\Bin\AjaxControlToolkit.dll" />
</Component>
How could I do this in .wxs file? Please suggest.
Assuming you are already using heat to generate your components, you can specify a variable by using -var <VariableName>. According to the docs this will:
Substitute File/#Source="SourceDir" with a preprocessor or a wix variable (e.g. -var var.MySource will become File/#Source="$(var.MySource)\myfile.txt" and -var wix.MySource will become File/#Source="!(wix.MySource)\myfile.txt".
I use this by running the heat command in the post-build event of the original project, and passing in -var var.$(ProjectName).TargetDir. The resulting File will have Source="$(var.ProjectName.TargetDir)\whatever.dll". As long as ProjectName is added as a reference to the wix setup project then the variable will be resolved properly.
I'm using Wix 3.6 beta from the command line, not as VS projects. I have a web application that is harvested with heat as a directory. This works. I'm using web.config transforms to manage each of the target environment web.config files. These are output with msbuild, this works and keeps things visible in Visual Studio and source control.
I've hit a problem deploying one of the several web.config files which I am manually including in product.wxs as components with conditions. I was expecting to include all components as deployable features and let the conditions select just one as active. For example:
<DirectoryRef Id="wwwroot">
<Component Id="setup_a" Guid="some_guid" >
<File Source="$(var.ConfigSourceDir)\setup_a\web.config" />
<Condition>ENVIRON = setup_a</Condition>
</Component>
<Component Id="setup_b" Guid="some_guid" >
<File Source="$(var.ConfigSourceDir)\setup_b\web.config" />
<Condition>ENVIRON = setup_b</Condition>
</Component>
This didn't create any file renaming, moving or deleting issues, but has the very fundamental problem that multiple web.config files are mapped to the same destination and this gives me a light error of "Product.wxs(xxx) : error LGHT0091 : Duplicate symbol 'File:web.config' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique."
An alternative approach was to use different named .config files and rename/move one to be the web.config, so something like:
<DirectoryRef Id="wwwroot">
<Component Id="setup_a" Guid="some_guid" >
<File Id="setup_a.config" Source="$(var.ConfigSourceDir)\setup_a.config" />
<CopyFile Id="moveit" SourceDirectory="wwwroot" SourceName="setup_a.config" DestinationDirectory="wwwroot" DestinationName="web.config" />
</Component>
This doesn't throw an error, bot the CopyFile command does nothing at all. I just get setup_a.config in the wwwroot folder.
If I nest the CopyFile inside the File, the copy action then works:
<DirectoryRef Id="wwwroot">
<Component Id="setup_a" Guid="some_guid" >
<File Id="setup_a.config" Source="$(var.ConfigSourceDir)\setup_a.config" >
<CopyFile Id="moveit" DestinationName="web.config"/>
</File>
</Component>
...but nested CopyFile means I can't add (it's disallowed) the Delete="yes" attribute to create a 'move' action. Instead I'm left with both setup_a.config and web.config in the wwwroot folder. Alternatively, if I add a seperate removefile within the same component element it also does nothing:
<RemoveFile Id="removefile" On="install" Directory="wwwroot" Name="setup_a.config"/>
</Component>
So, I'm hoping for a working example of how handle multiple web.config files in a conditional deployment, that doesn't leave files behind. the destination filename of web.config is fixed by the framework and can't be changed. The different configs are also pre-generated outside of wix using config transforms, this also can't be changed but the generated filenames could be anything.
cheers!
You complicate it too much. This should work:
<Component Id="setup_a" Guid="some_guid" >
<File Name="web.config" Id="config_a" Source="$(var.ConfigSourceDir)\setup_a\web.config" />
<Condition>ENVIRON = setup_a</Condition>
</Component>
<Component Id="setup_b" Guid="some_guid" >
<File Name="web.config" Id="config_b" Source="$(var.ConfigSourceDir)\setup_b\web.config" />
<Condition>ENVIRON = setup_b</Condition>
</Component>
Pay attention to a couple of things here:
the File/#Name is the same - that's the target file name you'd like to have (web.config)
the File/#Id is different for each File in order to avoid the light error you mentioned first
the File/#Source can be anything - it just describes what file to take as a source
In this sample light will still complain with warning LGHT1076, but that's just a warning - it pays your attention that conditions MUST be mutually exclusive to avoid problems.
I usually take a different approach. Rather then placing multiple mutually exclusive files into an installer that are tightly coupled to specific instances I put a generic file in the installer and use XML changes to transform the XML with the variation point data such as connection string and what not.
This allows me to make installers that can be deployed anywhere silently just by passing a few properties and the command line.