I've got a VS2008 deployment project that builds an installer for a couple of Windows services.
Each service references several different projects:
CustomerName.MailSendingService -> CustomerName.Network -> CustomerName.Data -> CustomerName.Security CustomerName.ProductIntegrationService -> CustomerName.Core -> CustomerName.Security
The Windows service projects, the projects they reference, and the deployment project are all in the same VS2008 solution.
I've added the primary output from the Windows service projects in the deployment project's file system editor.
My expectation is that the primary output for the Windows service projects would include the DLLs from the referenced projects. However, when the deployment project is built, the DLL from one of the referenced projects is missing. (CustomerName.ProductIntegrationService is missing CustomerName.Security)
Maddeningly, the DLLs for the other projects referenced by the Windows service are present; just one project's output is missing.
(Edit) I've verified that the reference is set to Copy Local in the reference properties window. The DLL for the referenced project is placed in the windows service project's bin\Release folder, but isn't packaged in the MSI file built for the deployment project.
(Edit 2) Following Joseph Daigle's suggestion, I checked that the dependency is in the dependencies list for the primary output, and it's not marked "excluded," so that doesn't appear to be the cause of this issue.
Why would just one project's output be missing?
I have a couple more things to add after reproducing the same suspected msi defect.
1) When I added the second project output sharing the same detected dependency to the installer it did not automatically add the dependency. I removed both project output's and added them back in reverse order. The second project output added never added the detected dependency. This excludes any configuration or code issue with the projects and how the references were added. It's always the second one that fails.
2) My team actually hit a second problem after using the 'Manually add detected assembly' workaround. Initially we added the dependency from the location in '\Program Files\xxx' but ran into build problems on 64 bit machines where that same dependency was in the '\Program Files (x86)\xxx' folder even though VS is smart enough to handle this problem when picking up references.