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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Hi, all

I have the same problem with dependencies and I've not solved it. I've even added real using of my assemblies such as:

MyAssembly.Foo.bar();

But output still empty.

Any idea?

Answer 5

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.

Answer 6

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.

Answer 7

Hi guys, 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

Answer 8

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.