I am including the VS 2005 merge modules into an MSI. The code is in place and the MSI builds.
<Fragment>
<DirectoryRef Id="TARGETDIR">
<!--
WiX docs say "There is generally no need to include the policy MSMs as part of the installation.", but, the former Installshield
project did include it, so, including here now. Remove it if it's actually not required.
http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html
-->
<Merge Id="VCRedist2005_32" SourceFile="$(var.RESOURCES)\MergeModules\VS2005\Microsoft_VC80_CRT_x86.msm" DiskId="1" Language="0"/>
<Merge Id="VCRedist2005_64" SourceFile="$(var.RESOURCES)\MergeModules\VS2005\Microsoft_VC80_CRT_x86_x64.msm" DiskId="1" Language="0"/>
<!--
<Merge Id="VCRedistPolicy2005_32" SourceFile="$(var.RESOURCES)\MergeModules\VS2005\policy_8_0_Microsoft_VC80_CRT_x86.msm" DiskId="1" Language="0"/>
<Merge Id="VCRedistPolicy2005_64" SourceFile="$(var.RESOURCES)\MergeModules\VS2005\policy_8_0_Microsoft_VC80_CRT_x86_x64.msm" DiskId="1" Language="0"/>
-->
</DirectoryRef>
</Fragment>
And in my Product.wxs:
<Feature ...>
<ComponentRef Id="Client_Registry" />
<?if $(var.Product) = xx ?>
<MergeRef Id="VCRedist2005_32"/>
<MergeRef Id="VCRedist2005_64"/>
<!--
<MergeRef Id="VCRedistPolicy2005_32"/>
<MergeRef Id="VCRedistPolicy2005_64"/>
-->
<?endif?>
</Feature>
I am concerned about two warnings though:
1>light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as we do not find CRT.Policy.63E949F6_03BC_5C40_FF1F_C8B3B9A1E18E#0 v in ModuleSignature table
1>light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as we do not find CRT.Policy.4F6D20F0_CCE5_1492_FF1F_C8B3B9A1E18E#0 v in ModuleSignature table
Two messages because I am including both the 32 and 64-bit merge modules.
I did not add the policy files because the wix page suggests not to. A MS blog page also backs that up. But, then there are pages such as this one, where the advice is TO include them.
So, I am unsure how to proceed. Should the policy files be included or not? And if not, why not?
I've always preferred to bootstrap the vcredist runtime instead. Keeps my MSI all nice and clean with no issues.
Related
We recently upgraded DevExpress. Since we have a custom theme, we had to upgrade the custom theme too.
That was the easy part. Now I'm trying to upgrade the setup to match the new file.
So basically, I'm changing the <File .../> of one <Component .../>:
From
<Component Id="Lib_Various_Files" Guid="9C621EB0-12E6-4D1D-8B5B-4150A76E33AA" KeyPath="yes" SharedDllRefCount="yes">
...
<File Id="DevExpress.Xpf.Themes.PreviousTheme.v17.1.dll" Name="DevExpress.Xpf.Themes.PreviousTheme.v17.1.dll" ReadOnly="yes" Vital="no" Compressed="default" DiskId="1" Source="$(var.DirLib)\PreviousTheme\DevExpress.Xpf.Themes.PreviousTheme.v17.1.dll" />
</Component>
To:
<Component Id="Lib_Various_Files" Guid="9C621EB0-12E6-4D1D-8B5B-4150A76E33AA" KeyPath="yes" SharedDllRefCount="yes">
...
<File Id="DevExpress.Xpf.Themes.OurTheme.v17.2.dll" Name="DevExpress.Xpf.Themes.OurTheme.v17.2.dll" ReadOnly="yes" Vital="no" Compressed="default" DiskId="1" Source="$(var.DirLib)\OurTheme\.td\Publish\DevExpress.Xpf.Themes.OurTheme.v17.2.dll" />
</Component>
Now I've an error in the setup, which seems to have no links to this line:
error LGHT0204: ICE30: The target file
'qgikh9i6.dll|System.Windows.Interactivity.dll' is installed in
'[TARGETDIR]\OurProduct\Bin\' by two different components on an LFN
system: 'cmpF5730C92213BA3272DDA3A5657DFF782' and 'Lib_Prism'. This
breaks component reference counting.
[D:\ws\OurProduct-Nightly\SetupWix\SetupWix\SetupWix.wixproj]
We do reference this library, in the Lib_Prism component(which is then in another Lib_Various component, that reference Lib_Prism and Lib_Various_Files, but nowhere else.
Any idea what could be the issue?
So here is the complete components list of this file:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<?include ..\Common.wxi?>
<DirectoryRef Id="BIN">
<Component Id="Lib_Various_Files" Guid="9C621EB0-12E6-4D1D-8B5B-4150A76E33AA" KeyPath="yes" SharedDllRefCount="yes">
...
<File Id="DevExpress.Xpf.Themes.OurTheme.v17.2.dll" Name="DevExpress.Xpf.Themes.OurTheme.v17.2.dll" ReadOnly="yes" Vital="no" Compressed="default" DiskId="1" Source="$(var.DirLib)\OurTheme\.td\Publish\DevExpress.Xpf.Themes.OurTheme.v17.2.dll" />
</Component>
<Component Id="Lib_MicrosoftPractices" Guid="780097FD-40C9-417A-A2C3-7C2B44567BEC" KeyPath="yes" SharedDllRefCount="yes">
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\CommonServiceLocator.1.3\lib\portable-net4+sl5+netcore45+wpa81+wp8\Microsoft.Practices.ServiceLocation.dll" />
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\Unity.4.0.1\lib\net45\Microsoft.Practices.Unity.Configuration.dll" />
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\Unity.4.0.1\lib\net45\Microsoft.Practices.Unity.RegistrationByConvention.dll" />
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\Unity.4.0.1\lib\net45\Microsoft.Practices.Unity.dll" />
</Component>
<Component Id="Lib_Prism" Guid="0F937515-2248-4CD2-B2E9-3E121FA9D743" KeyPath="yes" SharedDllRefCount="yes">
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\Prism.Core.6.3.0\lib\net45\Prism.dll" />
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\Prism.Unity.6.3.0\lib\net45\Prism.Unity.Wpf.dll" />
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\Prism.Wpf.6.3.0\lib\net45\Prism.Wpf.dll" />
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\Prism.Wpf.6.3.0\lib\net45\System.Windows.Interactivity.dll" />
</Component>
<Component Id="Lib_MvvmValidation" Guid="8681DBA1-F83D-475B-BCB8-A54A1F05FF0A" KeyPath="yes" SharedDllRefCount="yes">
<File ReadOnly="yes" DiskId="1" Source="$(var.DirPackages)\MvvmValidation.3.1.0\lib\netstandard1.0\MvvmValidation.dll" />
</Component>
<Component Id="Lib_Protobuf_Net" Guid="AEE6F4EB-78E3-4EC5-AA88-D5CC29D683D0" KeyPath="yes" SharedDllRefCount="yes">
<File ReadOnly="yes" DiskId="1" Source="$(var.DirDotfuscated)\ProtobufNet.dll" />
</Component>
</DirectoryRef>
<ComponentGroup Id="Lib_Various" >
<ComponentRef Id="Lib_MicrosoftPractices" />
<ComponentRef Id="Lib_Prism" />
<ComponentRef Id="Lib_Various_Files" />
<ComponentRef Id="Lib_MvvmValidation" />
<ComponentRef Id="Lib_Protobuf_Net" />
</ComponentGroup>
</Fragment>
</Wix>
Looking at your source file there are several problems with your component reference counting outright. You should never install several binaries with one component - it is a direct violation of the component rules. This causes exactly the kind of problems the error message indicates.
I recommend using a single file per component because that solves a plethora of possible reference count issues and upgrade problems. The shared-dll ref counters can also cause some blues I think. Do you have a legacy installer that you are trying to be compatible with? If not, then there is no reason to enable this component option - it increments the legacy SharedDLL ref-counter used by older, non-MSI installer technologies.
Now, for the issue where you change a file name in an existing component. This is also a violation of the component rules. You can not change the absolute file name of a component's key path and keep the same component GUID - this breaks component referencing. There must be a 1-to-1 correspondence between an absolute installation path and a component GUID.
The component GUID doesn't follow the file around if it moves, and the file "moves" when you change its file name (its absolute installation path has changed). There is an explanation here with an example: Change my component GUID in wix? (recommended read - decode this MSI peculiarity and things will be clearer going forward).
If you change a file name you can either:
Set your component GUIDs to auto-generate by deleting the whole GUID section in your source. The GUID will then be generated to be stable as long as the installation target path remains the same, and when you change the file name - for example - a new GUID will be generated for you auto-magically by WiX. See this answer for sample: Syntax for guids in WIX?
Set a new, hard-coded GUID yourself for the components where you change the file name that is being installed. This can be easy to forget - hence the recommended auto-magic described in point 1.
What you should actually do when file names change is to remove the old component and add a new one with the new file name. However, changing the GUID of an existing component and changing the file name has the same effect (same as deleting the old component and adding a new one).
With that said, there are bigger problems with this source as explained above. For future reliability you must split these components into one file per component. This causes interference between your old and new version and in order to clean this up, you can:
Set a totally new installation path for your project and use a single component per file from now on and you can use WiX's auto-magic component generation feature as explained above. This will work. Setting a new main installation folder "breaks the link" to "past component referencing sins".
Or you can uninstall the existing installation early during your major upgrade by moving RemoveExistingProducts early in the InstallExecuteSequence of your newest MSI version. This also wipes the slate clean of any component referencing issues and you can change your source to use one file per component going forward. If you use the MajorUpgrade element this change is easy - just set Schedule="afterInstallValidate". That should work (no time to test).
That should be it - if I have understood your scenario correctly.
Sample WiX extract for the proposed, new version:
<DirectoryRef Id="BIN">
<Component Feature="Product">
<File Source="$(var.DirLib)\OurTheme\.td\Publish\DevExpress.Xpf.Themes.OurTheme.v17.2.dll" />
</Component>
<Component Feature="Product">
<File Source="$(var.DirPackages)\CommonServiceLocator.1.3\lib\portable-net4+sl5+netcore45+wpa81+wp8\Microsoft.Practices.ServiceLocation.dll" />
</Component>
<Component Feature="Product">
<File Source="$(var.DirPackages)\Unity.4.0.1\lib\net45\Microsoft.Practices.Unity.Configuration.dll" />
</Component>
<Component Feature="Product">
<File Source="$(var.DirPackages)\Unity.4.0.1\lib\net45\Microsoft.Practices.Unity.RegistrationByConvention.dll" />
</Component>
<...>
</DirectoryRef>
Notice the tersified source with all attributes that can be auto-generated left out and all components now containing a single file. There is also direct specification of what feature each component belongs to as an attribute of the Component element. I find that this yields the least complicated and most flexible WiX source files. Preferences vary - obviously.
I would not roll with your current "multiple binaries per component" setup going forward. There will be more trouble if you do - almost guaranteed. MSI bites back - sorry to say - there are many bear traps. MSI has aspects that border on anti-patterns. The problems are faced by almost everyone. There is a section towards the bottom here on potential anti-patterns and also on the great benefits MSI yields for corporate deployment (just for reference): How to make better use of MSI files.
I am not particularly keen on this chaotic write-up of common MSI problems, but here it is: How do I avoid common design flaws in my WiX / MSI deployment solution? Maybe it can help to avoid some very common problems.
I finally found the issue:
It appears that DevExpress bin directory packs the System.Windows.Interactivity.dll library. So before we were not copying it and we didn't had it in our Lib\DevExpress folder.
It appears that we generate a componet with all Dll contained in the Lib\DevExpress folder, and therefore the System.WIndows.Interactivity.dll was contained in 2 differents packages.
I removed it from the DevExpress folder and now everything works fine. Sorry for the trouble.
I'm trying to generate Wix source from a custom Visual Studio extension. As such, I'd like to be able to (somehow) just add one file (plus project reference) to the Wix Project, and have the new DLLs added in to the Product.
As an example:
<Product Id="*" Name="blah" Version="..." Manufacturer="foo" UpgradeCode="...">
<Package InstallerVersion="200" ... />
<MajorUpgrade DowngradeErrorMessage="..." />
<MediaTemplate EmbedCab="yes" />
<Feature Id="ProductFeature" Title="blah" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
<!-- Custom actions, Directories, etc .... -->
</Product>
Then in separate files (which I want to be generated), I have some Fragments:
<Fragment>
<DirectoryRef Id="MYINSTALLDIR">
<Component Id="CMP_FILE1" Guid="...">
<File Id="FILE1" Source="file1.dll" Assembly=".net" KeyPath="yes" />
</Component>
</DirectoryRef>
</Fragment>
and
<Fragment>
<DirectoryRef Id="MYINSTALLDIR">
<Component Id="CMP_FILE2" Guid="...">
<File Id="FILE2" Source="file2.dll" Assembly=".net" KeyPath="yes" />
</Component>
</DirectoryRef>
</Fragment>
So far so good. The problem is that I need to tie those together with something like:
<Fragment>
<ComponentGroup Id="ProductComponents">
<ComponentRef Id="CMP_FILE1" />
<ComponentRef Id="CMP_FILE2" />
</ComponentGroup>
</Fragment>
That works, but I don't want to do that, because it requires editing of the ComponentGroup when I want to add the next file.
So I want to try to localise the information into my added file. I can live with it always being part of the same Feature.
I tried adding the Feature attribute to Component element:
<Fragment>
<DirectoryRef Id="MYINSTALLDIR">
<Component Id="CMP_FILE1" Guid="..." Feature="ProductFeature">
<File Id="FILE1" Source="file1.dll" Assembly=".net" KeyPath="yes" />
</Component>
</DirectoryRef>
</Fragment>
but that didn't seem to add the Component to the parent feature (empty Media table warning from Wix on build, and Orca confirmed it).
I also tried adding the ComponentGroup to each generated file, but of course I can't duplicate Id attributes, and unique Id just pushes the coupling problem up into Feature...
Is there a way to add a Component without editing the ComponentGroup?
No. But you could generate (rather than edit) your ComponentGroup[#Id="ProductComponents"]. The file where it is defined can be "hidden" by generating it into the obj folder and dynamically adding it to the compile. This is effectively what HarvestDirectory and the other targets that call heat do.
While your extension is adding project references and files into the project, it can also add an MSBuild Include that defines a Target with BeforeTargets="Compile". That Target can do the generation and add the generated file to the Compile ItemGroup.
You just have to have a contract that the extension will use a particular ComponentGroup Id for this purpose. (Heat uses unique names for component and file ids to prevent conflicts. I suggest you do that too, especially for "hidden" source files.)
I need to define a Wix file component that may not exist in certain circumstances. Is there any way to do this? Condition elements in Wix all seem to work at install time, and I need something that'll detect at compile time if a file is present and build the installer accordingly.
It seems you need to check out the wix preprocessor. Check out wix documentation on the topic:
wix preprocessor
for example, suppose you have an environment variable called APPTYPE. If its value is set to 'Full', then MyApp_Full.exe will be included and processed by the wix compiler (candle).
<Component Id='MyComponent1' Guid='fff60f72-5553-4e6b-9bf0-ad62ab9a90b1'>
<?if $(env.APPTYPE) = Full?>
<File Name='MyApp_Full.exe' DiskId='1' Source='..\MyApp_Full.exe' Vital='yes' />
<?endif?>
...
</Component>
There is more! Variables, defines, conditionals. Check out that doc page.
As iwo said, preprocessor variables are your friend! However the example from iwo can (and will) violate component rules, as the component isn't 'stable'. Better to condition an entire component (or component group)...
<?if $(var.releasetype)=full ?>
<ComponentRef Id="Somefile.dll" />
<?elseif $(var.releasetype)=enterprise ?>
<ComponentGroupRef Id="SomethingElse" />
<?endif?>
And then include the Component and ComponentGroups in separate Fragment tags so that they will only be compiled when referenced :)
<Fragment>
<Component Id="Somefile.dll" Guid="*">
<File Id="Somefile.dll" KeyPath="yes" Source="SourceDir\Somefile.dll" />
</Component>
</Fragment>
<Fragment>
<ComponentGroup Id="SomethingElse">
<ComponentRef Id="Somefile.dll" />
<Component Id="AnotherFile.dll>
<File Id="AnotherFile.dll" KeyPath="yes" Source="SourceDir\AnotherFile.dll" />
</Component>
</ComponentGroup>
</Fragment>
Personally I use nant to call candle and light targets, defining different variables for various different builds and products, effective use of fragments and preprocessor variables provides a great opportunity for code re-use between projects, or various releases of the same project.
In your case, to check if a file exists... then you'd just use the internal functions to define, or redefine a variable that is later passed to WiX. e.g.:
<if test="${not file::exists('something.dll')}">
<property name="releasetype" value="blahblahblah" />
</if>
I am learning Wix and I want to generate a setup.exe file instead of a setup.msi.
Is that possible?
A setup EXE is usually referred to as a bootstrapper or chainer. WiX 3.5 will ship with an executable called burn.exe, unfortunately this is still under heavy development.
If you're just after a basic self-extracting EXE with no additional logic you can use the included setupbld.exe with WiX. However it's pretty limited and only includes the most basic functionality.
Alternatively, 7-zip includes basic functionality for creating a setup.exe from an existing MSI. You will need to install the SFXs for installers addon first.
If you're after additional logic, dependency checking, etc. there are loads of alternatives. Personally I use IRMakeBootstrap, but have heard very good things about dotNetInstaller on the wix-users mailing list.
dotNetInstaller
IRMakeBootstrap (Commercial product, licensed as part of MSI Factory)
Visual Studio Bootstrapper (Supports dependencies, not sure about self-extracting exe though)
step 1.Create window application
step 2. Add setp project
step 3. Add reference
1.WixNetFxExtension.dll
2.WixNetFxExtension.dll
3.WixNetFxExtension.dll
step 4. Add folowing code
<Component Id="ProductComponent">
<File Id="installation"
source="E:\MyWork\WindowsFormsApplication2\
WindowsFormsApplication2\bin\Debug/
WindowsFormsApplication2.exe"/>
<!-- TODO: Insert files, registry keys, and other
resources here. -->
</Component>
step 5. <Property Id="WIXUI_INSTALLDIR"
Value="INSTALLFOLDER" ></Property>
<UIRef Id="WixUI_InstallDir"/>
step 6.
<Directory Id="DesktopFolder" Name="Desktop"/>
<Directory Id="INSTALLFOLDER" Name="SetupProject1"
/>
step 7. <ComponentRef
Id="ApplicationShortcutDesktop"/>
step 8.<Fragment>
<DirectoryRef Id="DesktopFolder">
<Component Id="ApplicationShortcutDesktop"
Guid="cde1e030-eb64-49a5-b7b8-400b379c2d1a">
<Shortcut Id="ApplicationDesktopShortcut"
Name="SetupProject1" Description="SetupProject1"
Target=".
[INSTALLFOLDER]WindowsFormsApplication2.exe"
WorkingDirectory="INSTALLFOLDER" />
<RemoveFolder Id="RemoveDesktopFolder"
Directory="DesktopFolder" On="uninstall" />
<RegistryValue Root="HKCU"
Key="Software\SetupProject1" Name="installed"
Type="integer" Value="1" KeyPath="yes" />
</Component>
</DirectoryRef>
</Fragment>
step 9.build and install setup
I am using the following code in my Wix Installer.
<DirectoryRef Id="TARGETDIR">
<Merge Id="CRT" Language="0" SourceFile=".\resources\Microsoft_VC90_CRT_x86.msm" DiskId="1" />
<Merge Id="ATL" Language="0" SourceFile=".\resources\Microsoft_VC90_ATL_x86.msm" DiskId="1" />
<Merge Id="MFC" Language="0" SourceFile=".\resources\Microsoft_VC90_MFC_x86.msm" DiskId="1" />
<Merge Id="MFCLOC" Language="0" SourceFile=".\resources\Microsoft_VC90_MFCLOC_x86.msm" DiskId="1" />
<Merge Id="OpenMP" Language="0" SourceFile=".\resources\Microsoft_VC90_OpenMP_x86.msm" DiskId="1" />
<Merge Id="CRT Policy" Language="0" src=".\resources\policy_9_0_Microsoft_VC90_CRT_x86.msm" DiskId="1" />
<Merge Id="MFC Policy" Language="0" src=".\resources\policy_9_0_Microsoft_VC90_MFC_x86.msm" DiskId="1" />
</DirectoryRef>
<Feature Id="VCRedist" Title="Visual C++ 9.0 Runtime" AllowAdvertise="no" Display="hidden" Level="1">
<MergeRef Id="CRT" />
<MergeRef Id="CRT Policy"/>
<MergeRef Id="ATL" />
<MergeRef Id="MFC" />
<MergeRef Id="MFC Policy"/>
<MergeRef Id="MFCLOC" />
<MergeRef Id="OpenMP" />
</Feature>
I feel that the msi build with this code works in many XP systems but fails in Vista. The programs and the shortcuts are getting created properly in Vista like XP.
What should I do in Vista to install these redistributables ?? I do not want to create a setup.exe with bootstrapper. My requirement states everything to be in a single msi only.
Any code example would help me a lot.
Thanks in advance for any valuable help.
Regards,
tvks
I thought that c++ redist is one of the packages recommended to be installed using the pre-packaged msi from MS. also i'm pretty sure all of the merge modules you included in your installer need corresponding policy merge modules not only crt and mfc.
another thing to check if your msi is elevating properly in Vista (UAC prompt)
In my current project we install the VC90 redistributables in the same way that you are describing in your post. We use the same attributes/values etc. However, we do not include any policy-modules. It works both under XP and Vista.
The Wix tutorial states that:
There is generally no need to include the policy MSMs as part of the installation.
So, if you have not given it a try, create an installation without any policies and see if that works better.