1
votes

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://docs.microsoft.com/en-us/windows/desktop/Msi/organizing-applications-into-components

1
I guess if you specify conditions on your components (see the Condition column in the Component table - docs.microsoft.com/en-us/windows/desktop/msi/component-table, and also see the VersionNT property docs.microsoft.com/en-us/windows/desktop/msi/versionnt), the components wont essentially both be installing the duplicate files. Only one component will install if configured properly. During validation you'll no doubt see ICE 30 warnings when you use conditions on your components though (docs.microsoft.com/en-us/windows/desktop/msi/ice30), but these can be ignored.Captain_Planet

1 Answers

0
votes

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).