问题
I have an .exe file and .dll (IE add-on) in a single MSI. When user installs it for the first time both the files will installs and in the program files under specified folder it will create .exe and .dll. Now I want to provide an update for the .dll (IE add-on) only. When I generate the MSI again with updated file of .dll how to omit the .exe file not to load in the MSI. Because .exe file size is very large it will take user lot of time to update the MSI. Is there a way to omit .exe component in the newly generated msi or please suggest me another ways to achieve this.
Product.wxs :
<?xml version="1.0" encoding="UTF-8"?>
<?define ProductVersion = "0.0.4"?>
<?define ProductUpgradeCode = "d3170abf-b41c-4274-a3a0-85576052f35c"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="saranSample" Language="1033" Version="$(var.ProductVersion)" Manufacturer="example" UpgradeCode="$(var.ProductUpgradeCode)">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of product is already installed." AllowSameVersionUpgrades="no" AllowDowngrades="no" />
<MediaTemplate EmbedCab="yes" />
<Upgrade Id="$(var.ProductUpgradeCode)">
<UpgradeVersion Minimum="$(var.ProductVersion)" OnlyDetect="yes"
Property="NEWERVERSIONDETECTED"/>
<UpgradeVersion Minimum="0.0.0" Maximum="$(var.ProductVersion)" IncludeMinimum="yes" IncludeMaximum="no" Property="OLDERVERSIONBEINGUPGRADED"/>
</Upgrade>
<InstallExecuteSequence>
<Custom Action="Filecleaner" After="InstallFinalize"></Custom>
</InstallExecuteSequence>
<Condition Message="A newer version of this software is already installed.">NOT NEWERVERSIONDETECTED</Condition>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="saranSample_$(var.ProductVersion)">
<Component Id="exeFiles" Guid="12345678-1234-1234-1234-222222222222">
<File Id="exe" Source="$(sys.CURRENTDIR)npp.7.5.7.Installer.exe" KeyPath="yes"/>
</Component>
<Component Id="dllFiles" Guid="12345678-1234-1234-1234-222222222223">
<File Id="dll" Source="$(sys.CURRENTDIR)saran.dll" KeyPath="yes"/>
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="ProductFeature" Title="saranSample" Level="1">
<ComponentRef Id="exeFiles"/>
<ComponentRef Id="dllFiles"/>
</Feature>
回答1:
Patching: This is essentially what patching is for - it only includes the "bits and pieces" of an MSI that has changed since the last release, excluding all other content from the binary distribution package.
Please be advised, though, that MSI patching is very complicated and essentially requires flawless packages with 100% compliance with regards to the MSI component rules - which is honestly rare in the real world (Rob Mensching's 101 on the component rules - He is the WiX creator). To succeed with this you need to be very careful how you do things in the MSI both with regards to component design, custom actions (complex conditioning, should they run during patching? Etc...), and other things.
Patching is merely a distribution mechanism for an upgrade that is already working. In other words you can package regular MSI updates such as major and minor upgrades as patches. Although major upgrade patches are theoretically possible, I have had better luck using minor upgrade patches, although minor upgrades are quite complicated to use in the real world. The other side of this is that no amount of patch testing or tweaking can work, if the original, full release package did not work properly.
Attempted Answer: So an attempted answer is that you can indeed deliver a smaller distribution patch package based on a working MSI update, but it is no picnic to make it work properly, and probably ill-advised if you have limited MSI experience and limited time to focus on learning the ins and outs of the technology. I guess you have to ask yourself how important this small distribution package really is in a world of broadband internet and fast computer I/O?
If forced to implement this patching, I would use a minor upgrade patch, and I would set the patch to not use bit-level patching. This means that only whole files are included instead of a binary diff of the previous and new binary - which I find to be unnecessary complexity and risk. The idea is to make the patch more robust (Why? What happens with bit-level patching when the file in question is signed? Frankly I have no idea).
Technical Details: Confession time: despite all my years of doing MSI I have never used WiX to create patches. I have used Installshield and Wise to make patches, and the latter is what worked for me (Wise). In order to use WiX to make patches the resource I know about to start with are these:
- http://wixtoolset.org/documentation/manual/v3/patching/ (official WiX documentation).
- https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/patchwork/
Some Selected Links:
- Easy pure-WiX patching with Melt
- Windows Installer Updates and Patches (from installsite.org)
- Updated instructions for building patches using the new WiX v3.0 patch building system
- Add missing file with msp patch (perhaps a more concise summary of what I have written above)
- Practical Patching Advice (rather ad-hoc)
- MSP vs. MSI packaging. Which to use for patches?
Microsoft Links:
- https://docs.microsoft.com/en-us/windows/desktop/msi/patching
- https://docs.microsoft.com/en-us/windows/desktop/msi/creating-a-patch-package
- https://docs.microsoft.com/en-us/windows/desktop/msi/what-happens-if-the-component-rules-are-broken
Further Links:
- Component Rules
- Using major upgrades for patches
- MSP does not replace a specific file
- patch uninstall not working properly developed using InstallShield
- patching using purely WIX
- More Patching Advice (generic)
- WiX patching not updating files correctly
来源：https://stackoverflow.com/questions/51472933/how-to-omit-a-component-when-we-try-to-build-msi-using-wix