Project dependency missing in deployment project

Question

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?

Bushcraft

This is still an issue in VS2010 for me – Deedradeeds

Answer 1

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.

• The proper way to manually add the assembly is by navigating to the bin folder and adding the assembly that is copied local. This ensures that the right assembly will be present on x86 or x64 machines.

Gottlieb

Answer 2

I can verify this is an issue for us as well. I suspect it's a bug in the deployment project - it only adds dependent project output in one location (maybe it thinks it's a COM dll?)

Manually adding Primary Output for the missing dll seems to be a viable workaround.

Dissuasion

Answer 3

I have not used Visual Studio 2008 yet, however in 2005 you have to verify that the missing reference on the project has the Copy Local property set to true.

This will copy the missing file to the output directory.

Lewls

Answer 4

In addition to hectorsq's response, verify that the depedency is in the deployment project dependencies list, and that the DLL in question is marked to be included.

Birdt

Can you clarify what you mean by "marked to be included"? I've verified that the dependency is in the dependencies list for the primary output, and it's not marked "excluded". – Bushcraft

Sorry, that is what I meant, that it is not marked as "excluded". Unfortunately it seems like it should be included, so I'm stumped. – Birdt

Answer 5

Have you tried looking at your dll in reflector to see if it really does depend on the other dll? VS is smart enough to not include a referenced assembly if it can see that you are not actually using it.

Added to that, even if you 'think' you're using it, VS can optimise away your use - this is a limit case but I have seen it:

For example, if you have a 'constants' assembly with this in:

public const string LockPanelUrn = "ApplicationRack.LockPanel";

VS will stick the string directly in your referencing code.

Beyond that, I'd suggest deleting and rebuilding your install solution.

Catenary

Answer 6

Did you add this assembly dependency after initially creating the deployment project? If so, you may need to right-click the Detected Dependencies folder and select Refresh Dependencies. It will pick up anything new that has been added since the last time you did this.

Deprive

I have done this, but in effect, at the "Primary output...", at the File System view, the property "Outputs" does not list the referenced dll's which causes me to think that it does not work like so. – Chic

Answer 7

check this out - maybe this not explains why is that, but at least it provides some workaround :)

http://lo-sharpdevs.blogspot.com/2009/07/vs-2008-disappearing-dependencies.html

Gine

Answer 8

I have had a similar issue with Microsoft SMO objects usage. I have a binary component (X.dll) that uses these Microsoft SMO objects that i've made myself. After compiling X.dll, I reference it in another EXE project using X.dll (and not the code). The installer project attached to that detects that it needs the Microsoft SMO Objects and detects that they are local to my SQL Server installation on the machine.

The component X.dll that uses the SMO Objects references the Microsoft SMO Objects via a local "Externals" folder i keep on a shared drive. All modules are compiled with reference to those, however my install project with my EXE project detects the ones from my SQL Server installation.

Because of this, we have another machine that has the "Externals" folder with SMO Objects, but the install project won't find the SMO objects from 'Detected Dependancies' anymore as it's not realising the SMO Objects are in the externals module! I'm not sure where it searches for the Detected Dependancy files, but it's not looking at where X.dll originally picked them up from, or even the EXE folder perhaps...

Agreed