I am writing an installer for a plugin. The plugin is a set of dll files created with a SDK, and renamed to other extensions (such as .dlo, .dle). Using these extensions is mandatory so that the software recognizes them as plug-ins and loads them.
Unfortunately, WiX seems not to be recognizing those as DLL files, and does not manage versions. Which is an issue in my case, since some files are shared between different plugin releases which can be installed together, and must be at the version of the newest plugin release.
Is there a way to tell WiX that these are legit DLL files?
Related
We have migrated our app from net472 to net6.0-windows. There is a wix installer for the app.
Currently the installer's upgrade sequence from net472 to net6.0-windows doesn't work as expected.
This is because there is a bunch of third party libs which have have the same file version for different platforms in net472 and net6.0-windows. e.g. NLog.dll would be 4.7.7.12472 in both platforms.
AFAIU, the file replacement rules work so that when source file(assembly in installer) and target file(installed assembly) version are equal, the installer will not replace this file.
So now after the upgrade, the bin folder is left with a mix of old(net472 from 3rd parties) and new(mostly our 'file version incremented' net6.0-windows) assemblies.
Any recommendations on how to solve this upgrade problem?
This is an example of broken component rules (by third parties). The windows installer thinks it's good because the versions are the same but the files are not forward or backwards compatible.
Unless you want to set the REINSTALLMODE property to amus (forced overwrite of everything ) or do file by file version lying (file version attribe 65535.65535.65535.65535 to force that file to always overwrite ) you will need to do a MajorUpgrde scheduled afterInstallValidate.
Other possibilities is to treat this as a new product and install to a new directory or consider alternate .NET compile/publish options so that the app self contains those files without the installer ever seeing them.
I have two installers:
Installer A installs A.dll v1.0.0.0
Installer B updates A.dll to v2.0.0.0
When I uninstall B, it does not delete A.dll. There is still A.dll with version 2.0.0.0
A.dll (v2.0.0.0) can be removed only from installer A.
Installers have different UpgradeCode and Component Ids.
How can I remove the replaced content of a Product from installer B?
Files that are shared between two setups (file is installed to the same absolute path by both setups) must maintain a single, stable component GUID to allow Windows Installer reference counting to work correctly. The mechanism to achieve this in Windows Installer is a merge module. WiX features its own way to handle shared files with the WiX include file approach.
I wrote an answer a while back with more information on merge modules and WiX include files here: WiX 3.8: Two MSI using the same registry values. How to delete registry values only if both MSI are uninstalled?
If you need to use different versions of the dll with different applications, then they should be installed to a private location for each application and they should have different component GUIDs:
ProgramFilesFolder\MyCompanyFolder\MyApp1\MyExe.exe version 1.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp1\MyDll.dll version 1.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp1\MyExe.exe version 2.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp2\MyDll.dll version 2.0.0
Alternatively you can install them to a shared location in separate folders and bind properly via your manifest:
CommonFilesFolder\MyCompanySharedFiles\1.0\MyExe.exe version 1.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp1\MyDll.dll version 1.0.0
CommonFilesFolder\MyCompanySharedFiles\2.0\MyExe.exe version 2.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp2\MyDll.dll version 2.0.0
CommonFilesFolder\MyCompanySharedFiles\2.5\MyExe.exe version 2.5.8
ProgramFilesFolder\MyCompanyFolder\MyApp2\MyDll.dll version 2.0.0
You can deploy the shared files with a separate MSI so they can be updated without recompiling your main MSI, or you can use a merge module to compile the shared files into your main MSI (sort of static linking).
Finally you can install the shared files to the GAC if they are .NET assemblies (but don't):
When and when-not to install into the GAC?
What are the advantages and disadvantages of using the GAC?
Or you can install native Win32 files to the WinSxS side-by-side folder. For native files you can also install shared in System32 or SysWOW64 or another non-side-by-side, but shared folder.
A similar answer here: Wix Toolset: How to restore replaced file on uninstall. Much more elaborate than the above description.
And here is a rather comprehensive (and verbose unfortunately) description of how Windows Installer component referencing really works: How exactly are files removed during MSI uninstall?
And finally an answer with some recommendations on how to improve and simplify WiX files by using default attributes and enabling automatic component GUID generation. Highly recommended for you to check out: Continue the Wix setup after having a service that could not start. Don't let the title confuse you, it is generic WiX advice. I particularly recommend looking at the automatic component GUID feature since it will help you do component GUID assignment correctly.
I've had some trouble getting WiX projects to build on build servers. One of the pain points has been that my WiX projects are referencing libraries in c:\program files... and the build process calls executables in the same path. This is a bummer because I have to install WiX toolkit in order to get my project to build.
What's the best way to eliminate this headache by having all build tools local to the project being built?
Is there a nuget package that does this? (At the time of writing it appears not, but I wanted to verify.) Package Restore capability would be nice because then I don't have to include the (many) WiX files in git.
If not, what do I need to download from WiX? What do I need to modify so that the compiler knows where to find the binaries to build WiX projects?
You can download just the WiX Binaries .zip from http://wixtoolset.org/releases/ then you can modify your wixproj file and update the <WixToolPath></WixToolPath> element to point to your WixBinaries
The WiX documentation has an article that explains how: Integrating Wix Projects into your Daily Builds
There is an unofficial nuget package at WiX.Toolset.
However, note that this seems to only be applicable to the setup project itself (i.e. it cannot be used to fetch wix binaries for e.g. a class library assembly).
I have a set of utility LabVIEW VIs that make calls to a custom DLL written in C++. I'd like to package the VIs into a LabVIEW toolkit and deploy it via an installer, but am unsure about the standard practices involved in doing this where a custom DLL is involved. I've looked at VIPM for packaging the VIs, but so far I haven't found a way to generate a package and include the appropriate DLL dependencies. What is the correct way to go about generating an installer for a LabVIEW Toolkit and installing the DLL dependency for said toolkit in the correct location (where ever that may be)?
The DLLs immediately known to the system - i.e., the ones entered in the CLFN node - are added automatically.
DLLs which are used indirectly and DLLs which are determined programmatically cannot be auto-included and must be added manually to the Source files section of the respective Build rule.
When my file set includes DLLs with one ore more dependencies to the C++ run-time DLLs I need to install the file from VCRedist.exe. This can be difficult, since each DLL is dependent on a specific version of the C++ run-time.
How do I add automatically the run-time redistributables to my installer?
How do I handle DLLs that require different versions of the C++ run-time in the WinSxS?
You need to install the latest version (highest) version required by your libraries and a policy file that redirects older versions to the new version.
You can do both with merge modules installed with Visual Studio. They're usually located in C:\Program Files\Common Files\Merge Modules. See MergeRef element and an example how to install Visual C++ redistributable with your installer. You will also need to add a policy merge module to your install.
You can simple make sure the latest vcredist is installed, it automatically includes support for older versions.
I think the easiest it to use bootstrapper to install the runtime before your installer runs. You might need to create your own package, but it is easy to use Bootstrapper Manifest Generator for this.
In the product.xml you can add an installation check to make sure it is not installed twice, for example:
<InstallChecks>
<MsiProductCheck Property="VCRedistInstalled" Product="{1F1C2DFC-2D24-3E06-BCB8-725134ADF989}"/>
</InstallChecks>
See here for other GUIDs.
Neither heat nor Votive does support the requested feature. The run-time DLLs must be added manually.