I have created a configuration tool which uses WiX to create MSI and with reference to previous MSI can build MSP.
This configuration tool will be used by even customer to create their MSI and MSP.
I will deliver the installer to customer (MSI or MSP)
Here I want to make sure that when customer are using it all GUIDs ProductCode, UpgradeCode, Component ID needed to be same...
One way of maintaining is storing all GUIDs in a XML file and store it as binary in installer and when customer creating their MSI or MSP they refer to the binary file in the MSI or MSP that I have provided.
I want you see is there any other way to do that?
you need to also store .wixpdb and msi file in your archive because for MSP Wix need wixpdb for reference and creating the patch. Refering the original configuration and files only possible if you keep a copy of .wixpdb and msi.
How to create MSP is there in wix tutorial...
Related
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
Scenario:
I have a merge module which contains certain assemblies, which get installed into the GAC.
This merge module is consumed by a msi package.
The merge module also contains GAC publisher policy files associated with each of the assemblies.
When the msi package is installed , several registry entries corresponding to these publisher policy files are created under:HKLM\SOFTWARE\Microsoft\Fusion\PublisherPolicy\Default. After an uninstall of this msi package, even though the actual publisher policy files and the assemblies are cleaned up from the GAC, the registry entries corresponding to the publisher policy files are not cleaned up.
Investigation carried out so far:
To summarize, the URL below states that the Windows Installer standard for including Publisher Policy Files within an installer is to add them directly to the MSI package and not a Merge Module. The problem with adding them to the Merge Module causes the associated Policy registry keys utilized by the CLR to be orphaned in the registry.
I believe the link below describes the cause of this issue and basically Windows Installer Standards indicate that Merge Modules should not be used to install Publisher Policy Files into the GAC. Perhaps the intention with installer validation is to force the Policy files to have explicit association to a specific Product Version.
Reference:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa369203(v=vs.85).aspx
In order to verify the behavior I manually modified the msi install package and removed the Policy file components from the ModuleComponents Table. By doing so removes the component reference from being associated to the merge module and directly assigns them to the MSI package.
After uninstalling, the Policy file registry entries are no longer orphaned in the registry and the problem is solved
Potential solution
The long term solution would be to redesign the Merge Modules to exclude the Policy files and add them directly to each Product MSI Package
Does anyone have any other better solution to fix this problem?
Regards,
Kiran Hegde
Is there any way to create minor upgrade (patch file i.e. .msp) or msi based on the old MSI installer and new MSi installer. we want to give the customer to minor upgraded patch (.msp or .msi0, which contains the changes only.
1) I have created (old) Test.msi, based on the 4 .wxs files. these 4 wxs files helps the installation wizard steps. Below are example.
Welcome.wxs file: where we mentioned just welcome message with reference of our project image
Main.wxs file: which contains the actual script of wxs sourcse file for the compononets and features.
InstallerPath.wxs: Where user can select his installation path
LicenseAgrement.wxs: license aggrement mentione dialog file.
2) I have changed the Product verison number only and modified few of my project files, and added few new files.
3) Then I have created (new) Test.msi, based on those 4 .wxs files.
4) By using these old and new installers, how can I genreate patch (.msp or .msi) for minor upgrade.
If you want to do this the two MSIs then this is a starting point:
http://wixtoolset.org/documentation/manual/v3/patching/patch_building.html
Then there's WiX patching:
http://wixtoolset.org/documentation/manual/v3/patching/wix_patching.html
Or as a variation on the first one, you could create your own .PCP file and run msimsp from the Windows kit as described here:
https://msdn.microsoft.com/en-us/library/aa367816(v=vs.85).aspx
Just to provide one more link, as an additional information to the last link, PhilDW gave already: Useful, if you want to call the patch generation by an own app/framework for patching. Then you could target the PatchWiz.dll from MS directly without using msimsp.
https://msdn.microsoft.com/en-us/library/aa370590%28v=vs.85%29.aspx
But MsiMsp is a simpler first entry of course. Basically it's just a shell for this dll.
But: Creating .pcp Files is not everybody's favor... reserved for people who want to go deeper here.
But IF you want it, it is probably safer of doing it with code than manually, once you have understood all the points.
I'm given a situation in which a file needs to overwrite, installed by a merge module, packed with same msi, i.e. this overwritten process should happen within same msi installation.
I actually tried with element but it didn't work.
I thought about adding Custom Action, but with two confusions:
When to launch this Custom Action?
If it removes the one comes with a merge module, Installer might try to restore it afterwards.
Any suggestions/solutions?
Thanks a bunch.
A merge module becomes a part of the MSI during the merge process. So inside your MSI there is no distinction between MSI files and MSM files.
The files in your package are installed based on their sequence in File table. So the only way to make a file overwrite a different file from the same package is to make sure it's sequence is higher.
I had the same problem and I solved it by removing the file (and the component) from the merge module using Orca. Then I added the new version of the file to my WiX project in the same way as all other files.
I want to patch an msi install. If the time stamp of an otherwise identical file is different in the baseline msi vs the current msi, will that be detected as a changed file and consequently be included in the resulting msp file? If yes, is there a way to avoid this?
The specific scenario is the following: Suppose baseline msi has dlls A and B and is built on date X - during the build process all dlls are generated. The new msi has dll A which changed and dll B which is the same and it is build on date Y - dlls A and B will also be build and have timestamp Y. Will B be included in the differencing msp file? (I use wix)
Windows Installer will generally not replace a DLL that shares the same version as its predecessor (and thus I'd guess WiX's build may exclude it). However if your DLL files are unversioned and you're not using companion files that have versions, the dates on the already-installed file can get involved in unfortunate ways: the file can be detected as user data and be excluded from replacement. See File Versioning Rules for details, along with its link to Default File Versioning.