Join us for SoftSummit 2023. The 20th anniversary of the industry leading software monetization conference. April 18 and 20. Register Now

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 3

.NET Scan at Build mishandles shared dependencies

This feature doesn't seem to do the right things for shared components. I have a project that has two shared .net dlls, and am using the Visual Studio integration in my IS project.

I have the exe's listed as key files using the "Project.primary output" feature in components by themselves, and have enabled ".NET Scan at Build" for "Properties and Dependencies". Right clicking on the "primary output" items in Files and Folders and selecting "Dependencies from Scan at build..." shows the correct items found.

Primary outputs from c# projects p1, p3, p4, p5, p6 are exe's which are the key files in components c1,c3,c4,c5,c6 respectively, and each has common .net dll dependency d1. p1 and p6 have common .net dll dependency d2. d1 and d2 are each the primary output of other projects in the solution (p7 & p8). Components are part of features f1,f3,f4,f5,f6 respectively.

When the installer is built, it the IS build log shows the correct files being found and inserted into the MSI. However, d1 and d2 are not treated as shared components. They are only installed with the first feature item which includes a component for which they are found as a dependency of. d1 is only installed with f5, and no other. d2 is only installed with f1, and not f6.

Beyond leaving out the necessary .dll's from other features, each feature that should contain d1 instead contains all the files (the key file and all others) from c5 (the one for which IS first finds d1 as a dependency). Each feature that should contain d2 instead contains all files from c1.

Looking at the resulting packed MSI confirms this. It looks like IS got it half right. It autogenerated components for each of the .net dlls that it found as dependencies: it placed d1 as the key file (and only content) of component ac1, and d2 into component ac2. It placed all the other ac's within the proper features, EXCEPT for the ones that should be shared among multiple features. In place of those, the feature contains the component first found for which the dependent executable is the key file. i.e., it used c5 in place of ac1 (which contains d1) in features f1,f3,f4,f5,f6, and used c1 in place of ac2 (which contains d2).

Amy I the only one using these "features" of IS? What the hell good is the "scan at build" if I have to keep track of all the dependencies manually for IS, and build my own explicit components to get around this?
Labels (1)
0 Kudos
2 Replies
Level 2

I am also facing the same problem. I am surprised why Install Shield can't automatically identify the required dependencies for each feature.:confused:
0 Kudos
Level 3

I think I understand what is happening. IS indentifies the same assembly as a different "component" from each project. It does not do the work of identifying that each is in fact the same one. In the end, each components gets copied over another onto the target machine, each with a ref count of 1. When you uninstall a feature that removes one of these seemingly common components, the ref count gets set to zero, and the file gets deleted.

IS should be doing the hard work of sorting out this commonality, and make a single, shared component between all the different features. This is a common situation.
0 Kudos