dotNetInstaller embeds all files in the same cab from different components with the same id, which results in unexpected behavior during run-time when filters are attributed to each component. #67

icnocop opened this Issue Mar 1, 2014 · 2 comments


None yet

1 participant

icnocop commented Mar 1, 2014

dotNetInstaller embeds files in the same cab from different components with the same component id, resulting in unexpected behavior during run-time.

For example, I have two components, one filtered for a 32-bit operating system, and the other filtered for a 64-bit operating system, with an embedded file with the same name in each component, and each component has the same component id.

I am re-using the same component id so that I can re-use the same /ComponentArgs command line option, independent of the operating system for simpler end-user documentation.

The setup installer that gets created contains a cab file in its resources which contains both embedded files of the same name.

Running the setup installer on a 32-bit operating system will extract the cab file which contains both embedded files, and the embedded file for the x64 filtered component will overwrite the x86 filtered component's embedded file for example, causing issues during run-time.

icnocop commented Mar 2, 2014

I'm thinking DNI should allow the user to specify a unique id for each component so that it can be used to keep cab files unique between different components that contain embedded files with the same name. The unique id would be a new, optional attribute for the <component /> element. If specified, it should be validated to be unique during linking.

icnocop commented May 20, 2016

When I explicitly specify the targetfilepath of the embedfile to be different than the other(s) with the same file name, it meets my requirements without any additional code changes, even if it's hard-coded and cannot be changed at run-time. Since this feature already exists, I don't think that DNI should behave any differently. 😃

@icnocop icnocop closed this May 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment