So I have a deployment project based on WIX. I notice that you can include features and files in there. However I only want to deploy a particular file if the DEV/QA environment is selected. If they select Production I want it to ignore this particular file.
Is there a way in the .wxi file to conditionally include a feature / directory & files based on a particular value of a variable?
ie. I want to have something like the below - potentially the componentRef included dynamically? (I have sanitised the values).
<Feature Id="MyApplication" Title="MyApp" Description="My Application" ConfigurableDirectory="MYAPP" Level="1">
<ComponentRef Id="AppEmailTemplatesDir" />
</Feature>
and then further down
<Directory Id="EmailTemplatesDir" Name="EmailTemplates">
<Component Id="AppEmailTemplatesDir" Guid="{A-GUID}">
<File Id="EmailTemplate1.htm" Name="EmailTemplate1.htm" DiskId="1" Source="..\..\EmailTemplates\EmailTemplate1.htm" />
</Component>
</Directory>
Any ideas? We do have custom Actions code (VB.NET) but I'm not sure how that could be used apart from writing code to include files.
There seem to be a variety of ways to do this ... this is what worked for me in Visual Studio 2013.
In the WiX project Properties / Tool Settings add this to Additional parameters / Compiler::
-dReleaseType=$(ReleaseType)
Create a component group containing only the additional file (this is left as an exercise for the reader)
In the main .wxs file add something like this where PDBFile is the id of the component group in step 2:
<!-- Installs a PDB file for daily builds -->
<?if $(var.ReleaseType) = daily ?>
<ComponentGroupRef Id="PDBFile"/>
<?endif?>
Run devenv to build the WiX project with ReleaseType set in the environment
Looks like I can use a Component NeverOverwriteOption="yes" option to ensure the installer doesn't overwrite the files when they exists.
Unless the environment conditional stuff was easy to figure out - this seems to achieve what I need which is to not overwrite the file on production.
I also found that on uninstall it was deleting all the folders (as expected) but to keep the template path I could use the Permanent="yes" attribute.
After discussion we've decided to keep all the files in source control and deploy them. But at least I learnt about NeverOverwriteOption and Permanent :)
Related
I have Wix project in which I need a common used dll library to be installed if it's absent.
If this dll exists I should not overwrite it.
So, when I set DefaultVersion="0.0.0.0" this dll is not overwritten if it exists, its ok. But when I delete app, the dll is beeing removed. How do I prevent removing dll in the case when it existed before installation?
I don't want to make it permanent because it should be removed if it didn't exist before installation.
<Component Id="myLib.dll" Permanent="no" Directory="Shared_Dir">
<File Name="myLib.dll" KeyPath="yes"
Source="mySource\myLib.dll"
DefaultVersion="0.0.0.0"
/>
Add reference to WixUtilExtension and xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" attribute to Wix element in your code.
Define <Property Id="Dll_Installed" Value="false"/> in Product element.
Add child <Condition>NOT Dll_Installed</Condition> to component myLib.dll.
Add that somewhere in your code:
<Fragment>
<util:FileSearch
Id="Dll_Installed"
Variable="Dll_Installed"
Path="[Shared_Dir]myLib.dll"
Result="exists"/>
</Fragment>
DefaultVersion attribute is not necessary.
The feature you are describing is reference counting. The Windows Installer reference counts with Components. Components are identified by their GUID.
So the normal way to address this requirement is to put the File in a Component and make sure the GUID of the Component is stable. The WiX Toolset should do exactly that automatically if if you do not specify the Component/#Guid attribute.
So the default behavior should just work for you.
The only other piece of the puzzle is the Windows Installer will install the latest version of a file. If the file version is the same or less the file will not be installed but will be reference counted.
Based on the details in the question it seems like you should be just fine with:
<Component Directory="Shared_Dir">
<File Source="mySource\myLib.dll" />
</Component>
One might ask why the Windows Installer use Components to reference count files. We'll, it allows you to group other resources, like registry keys, together and control their install as a unit. Much more important if you are installing COM servers than plain old files.
The Wix source code that I feed to the Wix compiler to build an MSI package for my application, contains the following PermissionEx directive, part of a file component which Windows Installer should install with additional (to those that should be inherited by default) permissions:
<PermissionEx Sddl="D:AR(A;;FW;;;BU)" />
As you can surmise, I intend to install the file with inherited permissions ("AR") included in its ACL and on top of that allow members of the Built-in Users group ("BU") to be allowed ("A") to write to the file ("FW").
The code above does not have the desired effect -- the file is installed, but only that single explicit ACE is listed, none of the ACEs that are supposed to be inherited from parent folder.
In contrast, if I subsequently remove all permissions from the file and run cacls file /S:D:AR(A;;FW;;;BU), i.e. specify exactly the same SDDL string, it does work as intended -- the permissions from parent are inherited and form part of the ACL, together with the explicit non-inherited ACE.
I am using Wix 3.11.1.2318 and the Windows Installer version is 5.0.16299.611, all running on Windows 10 Enterprise 64-bit. Orca tells me the MsiLockPermissionsEx table embedded in my built MSI file is populated with the intended SDDL record. So why is the file created without inheriting permissions from its containing folder?
I tried to use "AI" in place of "AR", and both strings together, but none of it had any effect either.
Is this some known limitation or a quirk with Windows Installer? I know that people were talking a while back how the old LockPermissions table (the one specified for Windows Installer versions earlier than 5) was inadequate in this specific regard -- inherited permissions, namely -- but they also said Microsoft was out to address this very issue with the new table feature.
Otherwise what am I doing wrong?
Given your knowledge in this field, you probably have already tried this. It would also be much better to eliminate the need for permissioning, but two snippets for you - notice the Append attribute:
Create a WiX project in Visual Studio. Add the Util namespace to the WiX element:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
In Visual Studio project, right click References and add reference to "%ProgramFiles(x86)%\WiX Toolset v3.11\bin\WixUtilExtension.dll".
Permission Folder:
<Component Feature="ProductFeature" Id="Test.exe" Guid="PUT-GUID-HERE">
<File Source="C:\Test.exe" />
<CreateFolder>
<util:PermissionEx User="Power Users" GenericWrite="yes" />
</CreateFolder>
</Component>
Permission File:
<Component>
<File Source="C:\Test2.exe">
<util:PermissionEx Append="yes" User="Users" GenericWrite="yes" />
</File>
</Component>
Take a look at WiX's custom PermissionEx in the Util extension.
http://wixtoolset.org/documentation/manual/v3/xsd/util/permissionex.html
I'd like to parse merge module files into two different locations. Is it possible?
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="MergeRedirectFolder">
<Component Id="LoggerClient" Guid="*">
<File Id="log4net" Name="log4net.dll" Source="..\..\_Release\log4net.dll" KeyPath='yes' />
<File Id="LoggerLibrary" Name="LoggerLibrary.dll" Source="..\..\_$(var.Configuration)\LoggerLibrary.dll" />
<File Id="app.config" Name="app.config.xml" Source="..\..\_Release\app.config.xml" />
<File Id="msvcr110.dll" Name="msvcr110.dll" Source="c:\windows\sysWoW64\msvcr110.dll" />
</Component>
</Directory>
</Directory>
</Module>
<Merge Id ="MergeModule.msm" Language ="!(loc.Lang)" SourceFile ="_$(var.Configuration)\MergeModule.msm" DiskId ="1" />
I want the second file to copy to a different folder than the other files.
There is a concept for that, it is called a retargetable merge module. I have avoided used it - the concept doesn't seem right to me. I have not tried to make one with Wix.
I think you could combine a Wix include file (simple sample) with the new auto-generated component guids to deploy such duplicated files reliably by adding an Include statement where appropriate. You must not hard code the guids in this case, but let them be auto generated by the Wix compiler and linker.
Also have a read of WixLibs (Wix library files): http://robmensching.com/blog/posts/2008/10/10/what-are-.wixlibs-and-why-would-you-use-them/
Wix documentation; http://wixtoolset.org/documentation/manual/v3/overview/files.html
Merge modules are for installing common runtimes and genuinly shared files. Typically C and C++ runtimes and other, similar libraries that should be available in the latest version for all applications.
Your files look like they are part of your application folder, with the exception of msvcr110.dll which you should remove and allow to be loaded from the system folder.
If the remaining files have no per-machine registration (COM for example or COM Interop), you can duplicate them in several folders without interference, yes, but why not load them from a shared location inside your own application folder structure?
%ProgramFiles%\My Company\My Shared Runtimes
%ProgramFiles%\My Company\My Apps\My App 1\
%ProgramFiles%\My Company\My Apps\My App 2\
These sample folders you "own" and you can deploy things here however you like. Not so for shared, system folders. You could make your own merge module for shared components between your applications into "My Shared Runtimes" and make your applications aware of the shared location "....\MySharedRuntimes\"
It depends on what you mean by different locations. You can build a merge module with 4 files, each in their own component and directory. One could go to the CommonFilesFolder; another to the SystemFolder; another to...you get the idea. So it's potentially easy if you make each file its own component in its own directory. However you've got them all under TARGETDIR, so you're going the wrong direction. You just define the other directory and that other component and file and you might be done, unless there's more to the question than meets the eye.
I would suggest contacting me privately for a few 30-60 minute conversation on MSI, component rules, Merge Modules and file set theory. It's too much to write. In a nutshell I would advise more merge modules.
In my Wix, I have lots of files included in this way:
<Component Id="mycomponent" Guid="*" Feature="Core" >
<Condition>$(var.Include) = 1</Condition>
<File Id="mycomponent.file" KeyPath="yes"
Source="$(var.BinDir)\mycomponent.file" />
</Component>
So I can pass in a different value of var.Include to generate packages for different environment.
While the resulting packages do seem to work, however I noticed the size of the packages are always quite big even when I set it to not include these components. It looks as if WiX is always including all components in building the msi, and only chose to not install these components when the package was build with var.Include = 0...
Is this a normal behavior?
The condition element is used to determine whether a component gets installed not whether it gets included in the build or not. Also be sure not to confuse Windows Installer properties used in Conditional Statements and preprocessor variables / statements. Two different beasts.
You can confirm by opening your MSI output file using some File compressing/uncompressing software such as 7zip and open the package.cab file inside the opened MSI file. and check whether your files with the id like "mycomponent" is present there or not.
I hope it is expected since it is dependent on the variable and that can be something which even can be set from install command call as install property.
UPDATE: You can amend the WIX like below by using Preprocessor statements, so it can exclude these optional component from the resulting msi
<?if $(env.MySku) = Enterprise ?>
<Component Id="mycomponent" Guid="*" Feature="Core">
<Condition>$(var.Include) = 1</Condition>
<File Id="mycomponent.file" KeyPath="yes" Source="$(var.BinDir)\mycomponent.file" />
</Component>
<?endif ?>
As #RinoTom and #Christopher point out, install-time selection (Condition tag) is very different from build-time selection (?if meta-tag). To be selectable at install time, the included components must be in the .msi . The advantage of this approach is that you can set the properties that determine their conditions, not only at build time, but at install time as well via dialogs or AppSearch.
But what you're asking for is multiple package builds, each tailored to a specific set of conditions, selected at build time. An alternative that might work for you is to define each of the optional components as a Fragment in a separate file. Then for each package configuration, compile only the fragments you want in it:
del /q *.wixobj
candle main_package.wxs
for %%f in (optional_1.wxs optional_5.wxs optional_27.wxs) do candle %%f
light *.wixobj -out tailored_package_A.msi
Since only those fragments you wanted included have been compiled to .wixobj, only they appear in the output package. This scales particularly nicely if you have some components that are always present, but only a handful that are optional.
it might be a stupid question, but i've spent few hours testing various possibilities and didn't find the answer.
I have one standard merge module prepared in VS 2005 (its probably fine, i've prepared standard VS 2005 setup project, included the merge module and it worked properly)
Wix project(mainly because GUI reasons) to take care about the installation. Code samples(shortened for brevity)
Directories part:
<Directory Id="INSTALLLOCATION" Name="sth">
<Merge Id='MyModule3' Language='1033' SourceFile='MergeModule.msm' DiskId='1' />
</Directory>
Feature part:
<Feature Id="ProductFeature3" Title="Tit" Level="1" Description='Yeah' ConfigurableDirectory='INSTALLLOCATION' Display='expand'
AllowAdvertise='no'>
<MergeRef Id='MyModule3' />
<ComponentGroupRef Id="Product.Generated" />
</Feature>
After building WIX project it throws errors like:
ICE83: Both MsiPublishAssemblies AND MsiUnpublishAssemblies actions MUST be present in InstallExecuteSequence table.
ICE83: The MsiPublishAssemblies action MUST be present in AdvtExecuteSequence table.
I've added lines:
<InstallExecuteSequence>
<Custom Action="PreventDowngrading"
After="FindRelatedProducts">NEWPRODUCTFOUND</Custom> //i suppose it doesnt influence nothing here
<MsiPublishAssemblies Sequence="1502" />
<MsiUnpublishAssemblies Sequence="1501" />
</InstallExecuteSequence>
And:
<AdvertiseExecuteSequence>
<MsiPublishAssemblies Sequence="1502" />
</AdvertiseExecuteSequence>
After that buildling process doesn't return any errors, but despite installing the feature (selected on feature list) there are no feature files on the HDD. I think it might be caused by Sequence numbers but i haven't got any ideas how to fix them, anyone can help?
If more info is needed i'll surely provide it.
I can think of a number of things that can go wrong. I'd look at the install log to see if the files got installed, just not where you were expecting them to get installed. I've known VDPROJ MSM's to have a great many problems including authoring their directory tables incorrectly.
You might want to look at an open source project that I created called IsWiX (CodePlex.com). It's designed be a UI authoring tool for WiX Merge Module projects that also allows you the raw ability to add additional metadata using traditional WiX XML. The result is a very clean merge module that can be consumed by InstallShield, WiX, VDPROJ, et al.