I'm curious what is the best way to detect installed software in computer during wix installation. I know that it's possible to do in a lot of ways. like appsearch, registrysearch, directorysearch and filesearch.
I also know that in windows installer there is MsiGetProductInfo function and ComponentSearch in wix, which look for information based on guid.. and also one other possibility is searching in the registry HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall but there are more possibilities. HKCU, HKLM and 64 or 32bit?
For me the best option looks something like MsiGetProductInfo, where I can put the guid of the app I'm looking for and then I get info like installation dir, version..
I read a couple of articles and lots of people are doing this through registry search. and dir search. but what if a patch changes the structure of app dirs? Or changes the registry keys. The guid should be still unique through these changes.
Also my boss told me that he is against searching the registry. So what do you think about this? What is the best option to do it.
Edit: Additional question. it looks to me that not of all installation system using guid.
Related
I have a question about the rules organizing resources into components.
What I want to do is the following; There are two files (both 64bit) with the same filename but in different source locations and with different component GUID's;
C:\data\win7\driver.sys
C:\data\win10\driver.sys
I want both included in the installer and when the installer runs decide depending on the OS which of these two files will be installed in the same location:
C:\Program Files\MyProgram\driver.sys
Is this a violation of the rules regarding the components? (the main one applying would be the first one I would say:)
"Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies."
https://learn.microsoft.com/en-us/windows/desktop/Msi/organizing-applications-into-components
Actual Answer: Yes, installing different files to the same absolute path is indeed a violation of the MSI component rules - in
theory. As you have discovered reading the documentation. However,
seeing as only one file will make it onto the box, it is all semantics
really, there will never be two files installed. Still, the MSI will
probably not validate - you will see validation errors.
I am not sure of the technical implications, but could you make the
file name different based on OS? Then you simply put the files in
separate components and use different component GUIDs and condition
the component for installation or not. Full compliance instantly.
With all that said, it seems driver files are to be installed using
INF-files in standalone packages in the future. Please read below.
Component Rules, Pragmatically: This is a well-known problem indeed. I have this old answer that might be helpful: Change my component GUID in wix? It describes how the component rules work in practice, and how the idea is that you reference count an absolute path, and not a file per-se. Please read it to make it clearer. More links in this answer.
Driver Installation: We are supposed to know how to do this, but the rules keep changing (and another answer). Essentially drivers are to be distributed via Windows Update, or at least via a standalone package without the need for an installer in the future (until Microsoft change their mind again?). Windows Hardware Dev Center dashboard. As far as I understand the installation is INF-based (as before).
Question: Are you sure about that installation location? What does the documentation say? I thought sys files should go primarily to the Windows folder? Or the WinSxS folders (side-by-side win32 assemblies). As you understand driver installations confuse us all.
Windows 10 Detection: It appears to be a challenge to detect Windows 10 due to the new "evergreen versionlessness" of Microsoft. I have this old answer written up to summarize my current understanding of it: Windows 10 not detecting on installshield. Deployment tools such as Advanced Installer does the job for you and detects Windows 10 with simple measures. Not sure what Installshield does. The linked answer lists a few approaches to detect the version yourself - not sure which is the saner approach. Please read (and also please report any interesting findings when you have a successful package).
The old version of the setup was created with InstallScope="PerMachine".
The new version is intended to have InstallScope="PerUser"; it also needs to use the same registry keys as the old version creates.
The problem is that whatever values are stored under these registry keys during the upgrade will be overwritten at the end with the initial values stored by the old version. Even deleting these keys manually before the installation will make them reappear (with the wrong values) after the installation process.
I have tried creating a custom action and specifically delete these keys, but the result is the same.
How can I ensure that the old version does not interfere with the installation process of the new version allowing to delete the old Registry Keys and re-create them?
What I found to be working:
Performing a REPAIR immediately after installing the new version will yield the correct results!
Uninstalling the old version manually before installing the new one will not remove the keys, but will allow to overwrite them with the correct values.
You should define what kind of upgrade you are doing, and if it's a major upgrade then where is it sequenced in your major upgrade element, although...
Probably the main issue is that cross context major upgrades aren't supported by Windows Installer, so if you are doing a major upgrade you will end up with both products installed. That's not an upgrade, that's most likely just a collision. So assuming that you want only one of them to be installed at the end of all this, you will need to uninstall the older per-machine installation and then install the per-user. As to why the uninstall of the per-machine product doesn't remove the registry keys, there are many possible reasons, such as they were created by the app not the MSI, or the component was marked permanent, or the component has another client product on the system - a log of the uninstall might show what's going on.
I have to add this as an answer, too long as a comment. I will "evolve" it once you provide more information:
Why do you want to switch to per-user installation? In the MSI world this is not an ideal way to deploy. An application is usable per-user even if installed per machine. With a per-machine install you simply add the ability to write shared settings that should not be overridden by a user. And your application is easier to upgrade, uninstall, patch and manage overall.
Here are a few more links to explain some of the problems with per-user setups. They are real, I am only trying to warn people what problems they are most likely going to face (almost certainly going to face):
Having an issue with WIX upgrade
Understanding “Per-User” or “Per-Machine” context for application Setup packages
Are you deploying HKCU or HKLM keys? I would not recommend writing any HKCU values from your setup, they should be written by the application itself. A setup is for writing to HKLM and other places that require "elevated rights". It should never be used to write user preferences. There will be interference when you do upgrades (as you have experienced).
Where is the registry data you speak of stored? In a single MSI component or several? Is there anything else in that component that still needs to be installed without the registry keys? If you can, please add your source WiX file so we can see for sure.
I am sure that we can make all these problems go away if you follow our advice precisely. You are facing a very common MSI problem.
Let me attempt a tentative answer without having all the information:
Remove all HKCU registry information from your setup (if you can).
Update your application to write these HKCU values itself, and ideally write to a brand new location in the registry instead of the old one. For example HKCU\Software\MyCompany\MyApp\5 instead of HKCU\Software\MyCompany\MyApp. This "decouples" your old and new state, and you got room to maneuver and clean up things.
Making your application write the HKCU keys is not a hack, but the right thing to do. It will make your application much more robust and generally easier to QA for yourself and your team. You can "wipe the slate clean" during testing and start over without a reinstall - in order to focus on application testing.
Put any remaining HKLM settings in a single WiX component and set a good key path that will never be modified or deleted by the user or any other process. For example: HKLM\Software\MyCompany\MyApp\5\MyAppHKLMKeyPath = 1
If you discover that you have to override a value for each user (in other words change something for every user in HKCU), you can do this with this approach which combines what the setup does with the application itself: http://forum.installsite.net/index.php?showtopic=21552 (if this is important, please read the whole, linked thread).
I simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
I found that Wix v3 uses a tool (heat.exe) to "harvest" information into WiX fragments. Either I am looking in the wrong location, or this is thinly documented.
What is the best way to auto-generate a WiX fragment (likely using heat.exe) for a complex folder structure that contains media files:
Of varying types (ico/png/xaml/etc)
That may change regularly (names/locations/adds/removes)
That are classified as "Content" and included in a .csproj
such that they can be built into an installer via WiX and would withstand upgrades and patches with decorum?
Background Information
I found heat.exe, which seems to solve the autogenerate WiX fragment requirement
In getting the "dir" harvester working, I noticed the "project" harvester (commandline help)
Media is already in C# project file, and so noted that "-pog:Content" might do very well
Cursory search found out of date documentation that didn't mention "project" harvester
Realized entire project installer could probably done with "project" harvester, but was unsure how well this was supported, and what the pitfalls were.
Saw the generation of "PUT-GUID-HERE" and realized that autogeneration of guids would likely have upgrade/patch implications.
Realized that there must be people who use these tools for similar purposes and could probably point me in the right direction.
It was (fairly) pointed out that v3 is not yet "done" (thus the scarceness of documentation and tutorials). The sense that I get now is that it is non-trivial to automate this in my build scripts, and the tools are growing right now to ease this.
In my experience John Robbins' Paraffin solves alot of the issues with tallow.exe (heat.exe in v3). I'm not sure if Paraffin plays nicely with v3, but it might be worth checking out.
FYI, I've used Paraffin in a build process and it allowed me to remove the previous 2-3 step cleanup process that involved a powershell script.
For the upgrade implications of auto-generated setups, read this. The take-home message:
Windows Installer doesn’t let you
remove components in a minor upgrade
It is hard to guarantee that components continue to exist if you generate your setup automatically. Therefore you have to chose between auto-generation of components and the ability to do minor upgrades.
If you have some auto-generated components, then just stick to major upgrades. You can use this sample by Rob as an example.
Thanks for the background, I wasn't aware that they were working on a new version of Wix. According to the project page, it isn't RTM yet, so that may explain the problems you're having. I hope to hear from the WIX developers in one of the replies.
I can't help you use the under-development heat.exe features. However, I have been in your situation and my solution was to create a tool that took directory and file information as input and generated valid wix project files as output. A .vsproj file is just an XML file, and you can use XSL, C#'s LINQ, PowerShell, or a number of other tools to do the work. I personally have used (pre-LINQ) C#/XMLDOM to parse VS project files for this purpose.
Good Luck,
Dave
For documentation, check out the help file that is installed with WiX - WiX.chm provides the most up to date information (along with the command line -help option).
I've been trying to find some information on this. So far I've been using the version Key presence to do it, is there a better way ?
What's installed on a box is noted in several places, none of which reports everything, so you'll have to look at each to find where Media services install info is.
WMI classes:
Win32_ApplicationService
Win32_QuickFixEngineering
Win32_SoftwareFeature
Also MsPIDinfo:
http://www.mombu.com/microsoft/scripting-jscript/t-microsoft-programs-ids-277777.html
And, interestingly, uninstall info in the Registry at subkeys below:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall