<Component Id="ProductComponent1">
<File Id="Default.aspxName="Default.aspx"Source="..\WebApplication2\Default.aspx" />
</Component>
What modification would help include the same file from TFS rather than my local system.
I am not aware of any mechanism by which a WIX build can pull files directly from Team Foundation Server (TFS). If this is your intention, you could use a tf get command to pull the latest version prior to the WIX build. For more information on tf get see https://msdn.microsoft.com/en-us/library/fx7sdeyf(v=vs.100).aspx.
If the WIX project is part of a Team Build, the answer to this question may be relevant: Set location of binaries in wixproj file.
Related
I am using Wix to install an application. The trick here is that the application is being installed on top of another, third party application.
I am installing both using a bootstrapper.
The application I am installing on top of has a DLL that we have customized in OUR application, so I need to overlay the original DLL with ours.
What is happening is that our application installer seems to be refusing to install the DLL. The log shows this in the InstallValidate step:
Component: DotEditPanels.dll; Installed: Absent; Request: Local; Action: Null
I have tried all sorts of things to make this happen. I started with using A tag in the Component to delete the original DLL, followed by a to install it.
The component is getting skipped, as you see above.
I then went to using a Custom Action to delete the original DLL, which works fine, with just the in the Component. Same thing.
Trying a few more things, the Component currently looks like this:
<Component Id="DotEditPanels.dll" Guid="*" NeverOverwrite="no" SharedDllRefCount="yes">
<File Id="filF8E7A8CEDC214A73A82277F1BA3B677F" KeyPath="yes" Source="..\..\DotEditPanels-8.1-FP2\bin\$(var.Configuration)\DotEditPanels.dll" />
</Component>
All I need is for this new DLL to get laid down, and I can't seem to make the installer do it. Any ideas?
File overwrite rules are based on file versions, so if your file version is less than that of the installed file, that's the obvious explanation. This rule is the basis of patches, hot fixes, service packs and so on, so if your version control is doing it's job that existing version should be newer than yours. The assumption is also that Dlls like that are compatible with older apps that may already be installed.
Anyway, you mention an assembly, so if it's managed code then you can set AssemblyFileVersion to a version that will overwrite the existing Dll. Otherwise it defaults to the assembly version. If you need to keep the assembly version the same because clients are bound to it they will still be ok, then use file version to denote later versions and overwrite older versions.
I figured as much.
So, I actually "cheated". I added the DLL as a Binary object, then used a custom action to delete the original DLL and read the new DLL from the Binary object in the installer database and write it to the proper place.
Yes, I know it's probably not "kosher", but it is getting the job done for my purposes.
I have a very simple WiX project (version 3.7) that installs somes files (a .NET program version 6.0.0.0). I'm ready to release a new version 6.0.1.0 using the MajorUpgrade functionality in WiX.
I'm keeping the UpgradeCode the same in the Product element and I change the Version from 6.0.0.0 to 6.0.1.0
<Product Id="*" Name="MyApp" Version="6.0.1.0" Manufacturer="Me"
UpgradeCode="$(var.TheUpgradeCodeGUID)">
On a machine with 6.0.0.0 installed, I run the new installer.
The removal of the old version 6.0.0.0 runs ok (all installed files are being removed), but when the installer continues to install the new version, 2 files are missing: a 3rd party DLL and a 3rd party EXE (that haven't been changed) are not being reinstalled.
<Component Id="AutomaticUpdaterWPF.dll" Guid="*">
<File Id="AutomaticUpdaterWPF.dll" Source="AutomaticUpdaterWPF.dll" KeyPath="yes" Checksum="yes" />
</Component>
<Component Id="wyUpdaterProgram" Guid="*">
<File Id="wyUpdaterProgram" Source="wyUpdate.exe" KeyPath="yes" Checksum="yes" />
</Component>
All other files in the < ComponentGroup > (some modified, some unmodified incl. other 3rd party DLLs) are being installed correctly during the major upgrade.
If I click on "repair" after the major upgrade, the 2 missing files re-appear.
Also, if I install version 6.0.1.0 for the first time (no upgrade, but first installation on a clean machine), then those 2 files are installed directly and normally.
(tested on several Windows machine (XP, 7 and 8)
Anybody any suggestion what is wrong and how to fix it?
The log file provided shows that newer versions of a few files already on the machine:
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {015A4DC1-56F4-562B-96B5-B3BE0D45FA5F} since the same component with higher versioned keyfile exists
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {4B6A1404-3892-5BEF-AB47-8FE3149211A4} since the same component with higher versioned keyfile exists
I've seen this problem with this updater in the past. Christopher is correct. The updater updated its files but didn't tell the MSI (it doesn't update the MSI which is not the correct thing to do). The new MSI thinks newer stuff is on the machine, chooses not to install its files, but during the upgrade the old package removes the files (it doesn't notice that the versions are newer). Since the new installer chose not to install the files you end up with nothing... until the repair.
To work around the problem, you need to move your RemoveExistingProducts action later. If you're using the MajorUpgrade element then Schedule='afterInstallExecute' or Schedule='afterInstallFinalize' should do the trick. You'll need to be more careful with the Component Rules.
Also, IMHO, the 3rd party vendor should not be updating files outside of the MSI. Their decision is forcing your product into a particular way of upgrading.
A log file would help. My guess is it's based on where you have scheduled RemoveExistingProducts. I've seen situations where Costing figures out a file being installed is the same as a file already installed and decides to not install the file. Then the major upgrade occurs and you end up not having the file. The repair works because the file isn't there and costing realizes that it needs to be installed.
I have had the same problem. The issue here is when doing major upgrade, msi at first checks which components to install (and all dlls with lower version than the ones already installed are marked as "do not install"), then it removes installed app and then installs new version but without those previously marked components.
Rescheduling of REP did not help since "disallowing installation (...)" was done in Costing phase and MajorUpgrade can only be scheduled in Install phase.
My solution was to set REINSTALLMODE property to "amus" in wxs file.
<Property Id="REINSTALLMODE" Value="amus" />
The "a" means all dlls will be reinstalled despite their versions.
I had another solution to this problem, but the previous reply certainly pointed me in the right direction. The DLLs in my .NET project were being assigned a lower version number than my previous installation. Going to the AssemblyInfo.cs files and incrementing the third octet from 0 to 1 solved it. Wix now recognized the DLLs as newer.
[assembly: AssemblyVersion("1.0.1.*")]
Error still exists on installer 5.0 and is still a problem.
Workaround to place RemoveExistingProduct after InstallFinalize is no solution for us. I forced the update by property setting on the single file.
This solution works for us now.
On older versions of Windows Installer the issue is documented here:
https://support.microsoft.com/en-us/kb/905238
The list of affected products inplies that it's fixed in MSI engine 4.0 and later. Using the 4.5 redistributable before doing installs should help, if applicable to the OS version.
I've been asked to bundle Apple's Bonjour installer into our own msi installer, so that Bonjour automatically gets installed alongside our software. Anyone done this before? It doesn't seem to be trivial, as an msi installer cannot include and kick off another one. I assume I'd need some kind of batch file to run the two installers sequentially?
You'll need to use a bootstrapper to chain the Bonjour install with your installer. If you are using WiX 3.6 or later, using Burn to create a package bundle is a good option.
I found the Bonjour installer by downloading the Bonjour SDK and opening it in 7-zip, though I'm sure installing the SDK would provide access to it as well.
The way I typically like to do this is to add a new source file to your setup project for each dependency package to keep that logic separate from the main application setup.
The Bonjour package can be listed as a remote payload to retrieve on the fly, or build it into your setup. In this case, it seems more likely to build it in (Compressed="yes"). If you need to add any extra dependencies related to bonjour or parameters to pass into it, you could define them here as well.
<Fragment>
<!-- if a web link actually exists, I didn't find it... -->
<?define BonjourWebLink = "http://path/to/Bonjour.msi"?>
<PackageGroup Id="BonjourWeb">
<MsiPackage Id="BonjourWeb"
Compressed="no"
DownloadUrl="$(var.BonjourWebLink)">
</MsiPackage>
</PackageGroup>
<PackageGroup Id="Bonjour">
<MsiPackage Id="Bonjour"
Compressed="yes"
SourceFile="path\to\Bonjour.msi"/>
</PackageGroup>
</Fragment>
In your main bundle you just need to add a reference to the correct package group.
<Chain>
<PackageGroupRef Id="Bonjour"/>
<MsiPackage SourceFile="path\to\YourProduct.msi"/>
</Chain>
Since Bonjour uses MSI instead of an executable, you don't need to do anything to detect whether it is present or not; Burn will handle that for you. Actually, since WiX harvests most of the information your bundle needs from the MSI, this might be overkill, and you could just put in the MsiPackage element in your chain directly.
Don't forget to carefully check Apple's terms for doing this.
This would be a bit more work, and is prone to issues with upgrading, but you can take the Bonjour MSI and decompile it using dark. Convert the decompiled MSI into a Merge module that can be included with your installer, and you will have a single install. I have done this with some driver installs in the past, and it is usually not that complicated.
You need a bootstrapper; there are several freely available out there, including one being developed in WiX called Burn.
Wix Burn is relatively stable now.I`m using Wix 3.8.
If you are allowed to redistribute Bonjour Installer,you can chain the installer in Wix Burn. You can even put a condition to specify Bonjour as prerequesite for your installer.If it is not present,then Bonjour will be deployed, else it can be skipped.
You can check this link for understanding Burn.
http://wixtoolset.org/documentation/manual/v3/bundle/
I just realised I can not run my vdproj file from msbuild without calling Visual Studio.
What a showstopper for atomated builds!
Can you recommend another installer, that allows to compile your setup for a .NET 2.0 Winform-application from commandline?
WIX see:
http://wix.sourceforge.net/
Established, open source MSi based installer. Better still you can migrate buildt msi's from the output of your vdproj. Plus you not longer need to have visual studio to do your builds.
Most any other installer tool can. Inno Setup, NSIS, etc.
We have an automated build setup that uses calls .vdproj files from TeamCity. One key component is that we had to automate generating a new GUID every time we do a deployment build. (Perhaps that is the "showstopper" you were referring to.) Here is a workaround that supports it:
http://www.codeproject.com/KB/install/VersionVDProj.aspx
It parses your .vdproj file and updates the Package and Product codes. Here are some relevant snippets from our MsBuild file that do the deployment setup:
<Target Name="Update-Vdproj-Version">
<Exec Command="Tools\VersionVDProj\VersionVDProj.exe -msi Deployment\KillerAppSetup\KipperAppSetup.vdproj version=$(Release)" />
</Target>
<Target Name="Build-Setup">
<Exec Command="$(DevenvPath) KillerAppSetup.sln /build Release" WorkingDirectory="Deployment\KillerAppSetup\" />
</Target>
So, it can be done, and it is being done!:) Granted that Visual Studio Setup and Deployment projects are fairly primitive, but if they are all you need, this works.
Background:
I always try to ensure the following tenet in my projects:
After a fresh checkout a developer should be able to do all project related tasks with solely the contents of the combined folders.
Obviously, this isn't always possible (e.g. Visual Studio for Windows development). However, I really dislike having to install any third-party libraries or tools that are specific a project like log4net, NHibernate, NUnit, etc. There are number of reasons for this including:
For a given development machine, you may work on several different projects, all which leverage different versions of the same third-party library or tool.
Minimizing the environment setup requirements makes setting up new developers or machines much easier
Facilitates easier maintenance of automated builds
Assumptions/Contraints
I am currently using WiX 3 beta, but if there is way for either 2.0 or 3.0 please respond
I am using Visual Studio 2005
The IDE syntax highlighting is not a requirement.
Question:
Is it possible to avoid local installation of the WiX toolset and use flat files instead? If so, please explain how.
See Also:
First, build your WiX installer:
Create a new WiX Installer Project in Visual Studio 2005.
Build your WiX XML accordingly.
Now, to integrate the WiX toolkit into your source tree:
Copy c:\Program Files\Windows Installer XML v3\bin to a sub-directory in your source tree. I used WiX\bin relative to my .wixproj file.
Copy c:\Program Files\MSBuild\WiX\v3.0\ to a subdirectory in your source tree. I used WiX\v3.0 relative to my .wixproj file.
Either add the following code or replace the line that follows:
<WixTargetsPath Condition=" '$(WixTargetsPath)' == ''>$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets</WixTargetsPath>
With the following lines:
<WixToolPath>$(MSBuildProjectDirectory)\WiX\bin\</WixToolPath>
<WixTasksPath>$(MSBuildProjectDirectory)\WiX\v3.0\WixTasks.dll</WixTasksPath>
<WixTargetsPath>$(MSBuildProjectDirectory)\WiX\v3.0\Wix.targets</WixTargetsPath>
As you can see, the WixToolPath, WixTasksPath and WixTargetsPath directives reflect the location of the folders I've instructed you to copy.
Rename your .wixproj to .csproj. This ensures that Visual Studio does not get confused by the .wixproj file but because the .wixproj is a valid MSBuild project, Visual Studio will be able to work with it.
Using this method, the WiX directory as described is about 9MB large.
I know with WiX 2, you can just download the executable files and the dll's to whatever directory your project is in. Then you create a .bat file to run candle.exe and light.exe with the parameters you need to build your installer.
That way, all your projects can have their own version of WiX with a disk drive hit of only about 4 megs each.
I'm not positive, but I think you can do the same with WiX 3.