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.
Related
I have a couple of MSI files installing different applications. All these packages share the same underlying runtime which basically is a set of DLLs. This runtime is pulled in each of the installers as a merge module. Installing a couple of these packages works just fine, always the latest version of the runtime stays on the system and when the last package is removed everything is removed from the system.
Now I had to split one of the DLLs into 2 and added a new component to the runtime installing the new DLL. This new DLL is linked with other libs of the runtime. Now assume the following scenario:
install an old package with the merge module for the runtime without the new DLL
install a new different package with a newer version of the merge module for the runtime. Now there are 2 packages on the system
remove the new package again
Now the old package is broken because:
the new component for the new DLL had a reference count of one as the old package didn't have it and therefore gets removed
the other runtime DLLs stay on the system because they are still referenced by the older package. However as they are new they are already linked with the new DLL that is now no longer present
So my question is:
Is there either a way to explicitly state in the WiX code that file A depends on file B so that it stays on the system until all references have been uninstalled?
or is there a way to explicitly downgrade the dependees in a way the dependency does not longer exists?
Am I doing something fundamentally wrong?
What I did try on a clean machine was to follow Stein Åsmul suggestion like this:
<Component Id='OldLibsNowDependingOnNewLib' Guid='C8DCD2AB-CBE5-4853-9B25-9D6FE1F678DD'>
<File Id='LibOne' Name='LibOne.dll' Source='$(var.SourceDir)/LibOne.dll' />
<File Id='LibTwo' Name='LibTwo.dll' Source='$(var.SourceDir)/LibTwo.dll' />
</Component>
<Component Id='NewLibComponent' Guid='CD2DB93D-1952-4788-A537-CE5FFDE5F0C8' Shared='yes'>
<File Id='LibNew' Name='LibNew.dll' Source='$(var.SourceDir)/LibNew.dll' />
</Component>
However unfortunately this doesn't change the behaviour.
UPDATE: Looking in the SDK again, I see the flag msidbComponentAttributesShared for components. This
looks promising for the problem you describe. Please try to enable
this flag and recompile the version 2 of your setup (unless it is
live).
Enable the Shared flag for the component in question (last part):
<Component Feature="Product" Shared="yes">
This seems to be for patch support, but maybe it will work for your case too. From the MSI SDK:
"If a component is marked with this attribute value in at least one package installed on the system, the installer treats the component as marked in all packages. If a package that shares the marked component is uninstalled, Windows Installer 4.5 can continue to share the highest version of the component on the system, even if that highest version was installed by the package that is being uninstalled."
I think the above should work, but don't have time to test right now. Leaving the below for review.
Short Answer: Use WiX's Burn (setup chainer) to install in sequence the application setup and a new, separate runtime setup that can be handled
independently of your application setup versions.
Prerequisite Setup: Interesting case. This is why I like to split prerequisites into its own MSI package and deploy it via a Burn Bundle Bootstrapper. Burn is WiX's bootstrapper / downloader / chainer - essentially a way to run several setups in sequence - in a few different formats such as MSI, EXE, MSU, MSP. When doing this - putting the runtime in its own MSI - there are no entanglements and you get good decoupling of your runtime and application-specific files. In other words: you can update the runtime files on its own - with their own MSI. The files will even have a reference count of 1 meaning you can easily uninstall them all (not if you install via a merge module that also can be included in other packages - more below).
Merge Modules - Semi-Static Linking?: In a weird way merge modules are sort of semi-static linking. The whole merge module is a version - a binary bundle (think COM) - but its installation behavior is one of "higher version wins" only. Hence a single newer MSI with the newest merge module in it will update the shared files for all applications that use them. Uninstalling will then do what you see: preserve the files that were originally installed by older setups.
Options: One "solution" in your case could be to re-compile the older setup with the newer merge module and then reistall, which I understand you don't like. I don't like it either. I guess it is no solution at all. Some other suggestions:
Permanent component: You can set the hosting component for the new file to be permanent on the system. This is very easy, but also quite silly and not always very desirable. Uninstall will then not remove the file at all.
Prerequisite: This is my favorite option mentioned above. You compile a prerequisite MSI setup that installs the runtime components. This MSI can deliver updates to itself without affecting the main application. This is the primary benefit I am after: Cohesion & Coupling benefits.
Merge Modules: I would avoid merge modules altogether, but it is common to merge the same merge module into the prerequisite setup - if you have a merge module already.
In most cases merging a merge module is fine since you then install the prerequisite and then you can install and uninstall application versions at will without affecting the runtime since a different product (prerequisite MSI) installed the runtime - and that setup should stay behind and not be uninstalled.
If the merge module does not work and brings along the conflict that you already had, maybe try to combine with the msidbComponentAttributesShared "solution" mentioned above. Not tested by me so far. Always risky to suggest things like this, but it is "best effort".
WiX Include Files: I prefer to use WiX include files which allows me to pull in new files without re-authoring a whole merge module in binary format (think C++ include files as opposed to a merge module's COM-style binary reuse).
Side-By-Side: Many people prefer to install prerequisites side-by-side so that several versions of the runtime can co-exist. This may or may not involve the GAC. Switching runtime versions would then be a manifest-manipulation task. Generally somewhat confusing, but doable. You can use both merge modules and separate MSI files to deploy such runtimes - as described above. I would definitely use a prerequisite MSI.
I can't think of more right now, but I know I have forgotten something important this time. Let me persist what I have for now in case it sparks ideas for you.
Cumbersome Prerequisite Setups: Note that prerequisite MSI files are not so bad for corporate deployment since deployment systems will allow one to define relationships between MSI files and to set up deployment chains. For home users you can easily wrap everything in a large setup.exe.
Nonsense Options: Options that don't make sense would be to roll the new file into both setup versions. No gain, lots of overhead. Some people like to copy new files locally to the main installation folder. Does not work since the files it is linked to are likely elsewhere (runtime location). Static linking wouldn't be relevant in this case I think. Only as a last resort to solve a live problem I guess. Setting the SharedDllRefCounter flag will not affect MSI reference counting, it is for legacy reference counting (non-MSI setups), though tweaking this manually is an emergency "solution". The last resort people end up with is typically to abandon the runtime installation and install everything to the same installation folder. Then you have to always recompile everything for every release - which is what you want to avoid?
Some Links:
WiX (Windows Installer Xml), Create universal variables
Pre-Processor constructs, features, Burn Bundles and beyond
Background
WiX & the Windows Installer are completely new to me.
In production, we used an MSI (created using WiX) to install our software. The MSI references a third-party assembly (e.g. OtherCompany.ThirdParty.dll, version 2.5).
The next release of our software must reference an older version of the third-party assembly (e.g. OtherCompany.ThirdParty.dll, version 1.7).
While I understand that installing an older version of a dependency is uncommon, it must happen.
So my question is... how do you configure a MSI (generated by WiX) to use an older version of an assembly without having to completely uninstall the existing package?
Options
We have explored the following:
Increment the assembly's version
it's a third party assembly, and
for traceability this is not an option
rename the assembly
the dependency is being retrieved using NuGet... so this won't be straight forward
force existing install to be completely removed (automatically or manually)
we don't want configuration information that was collected during the previous installation to be lost, so this isn't an option
schedule RemoveExistingProducts before costing
not recommended by Microsoft (see: MSDN)
custom action: to delete dependency
if the installation fails, the application may be left in an undefined state
override file version in setup
moving forward, this will be error prone
changing the REINSTALLMODE
From the articles that I have read, it appears that this should only be used as a last resort.
use a WIX companion file
am still investigating
For Moderators
I am aware that there are other SO posts on this subject. Please note that several of the recommended solutions are incomplete or are error prone.
References
MSDN: Patching and Upgrades
MSDN: RemoveExistingProducts Action
downgrade a library during a msi upgrade
Why Windows Installer removes files during a major upgrade if they go backwards in version numbers
MSI Writing Guidelines
What Every Developer Should Know About MSI Components
Windows installer deletes versioned file during product upgrade, instead of downgrading it
MSDN: Windows Installer - File Versioning Rules
Msiexec REINSTALL=ALL REINSTALLMODE=vamus not reinstalling anything
good overview of what is happening under-the-hood
Forcing an upgrade of a file that is modified during its initial installation
this is an older post is from 2009
Some issues are best solved by the application design rather the deployment.
There are two places to save a particular version of a .NET assembly: the GAC or the application folder (or subfolder with probing privatePath). In either case, you might want to use a bindingRedirect.
Also, you can load from a specific location using AppDomain.AssemblyResolve, provided the binding is not successful using the GAC.
General Reference: How the Runtime Locates Assemblies—thanks to #Pressacco.
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 have written my first setup program using WIX (version 3.6). When uninstalling the application, an .InstallState file gets left behind in the app folder. Is this supposed to be removed, and if so, what do I need to add to my script to remove it?
I've searched extensively but haven't really come up with anything.
If this file is installed with your application, it should be removed automatically on uninstall.
If this file is created later, then you should add RemoveFile element with On="uninstall" into a corresponding component.
Someone asked a very similar question, but the response was unhelpful. It would be extremely valuable if there was a knowledgeable answer...
I have created a WiX project using Windows Installed 4.5. I included an EmbeddedChainer element reference in the wxs file for the MsiEmbeddedChainer Table, which allows multiple-package installation.
<EmbeddedChainer Id="Chainer" FileSource="InstallMSI.exe" />
I looked around the net and finally found a single post that showed how this person retrieved a handle for the internal transaction. Now, my installer correctly calls my executable to process the chained MSIs. However, uninstalling does not work. Please note that without the above EmbeddedChainer element, the uninstall works fine.
I've read all the available document and I cannot find a single example project.
Can anyone provide some guidance in creating a WiX based multi-MSI install package?
The WiX documentation for EmbeddedChainer refers to the MSDN documentation for MsiEmbeddedChainer Table, which in turn directs you to reference Monitoring an Installation using MsiSetExternalUI
Rather than looking for a WiX specific example, I suggest looking for any MSI example. From there it will be fairly easy to figure out where you're going wrong with WiX.
The same embedded chainer executable Main() will be called again when uninstalled. In order for the chainer code to detect whether to install or uninstall, the parent installer should pass the argument to the chainer Main function. When uninstall, the parent installer has the property [REMOVE] set to the either "REMOVE=ALL" or "REMOVE=feature1,feature2". Set the EmbededChainer/#CommandLine to "REMOVE=[REMOVE]" and in the Main of the chainer code, parse the argument list and pass the data to the MsiInstallProduct() as argument. When the MsiInstallProduct() see the argument "REMOVE=ALL", the child MSI will perform the uninstall.