.NET deployment of DLLs that the project does not use, but required DLL queries require

Question

So, the problem is quite simple: my project refers to assembly X, but not to Z. But in assembly X, reference is made to assembly Z. Assembly Z is updated more often, so whenever I build my project, I would like to get the latest version Z.

So far I have 3 options:

• refers to assembly Z. This always has the advantage of getting a new version. But it pollutes the links with what is not strictly required there.
• Add a post-build event that copies the necessary DLLs from where they are being updated. I think this is fine until I need a few different DLLs, which would make the script quite long and tedious to support.
• Add assembly Z as a resource and set the output copy to true. I probably would prefer this, except that when I add the DLL to the project, visual studio actually copies (then) the current version to the project, and there is no link to the original source. Thus, when the assembly is updated, it is in no way reflected in my project. If I do not combine this approach with option number 2, but then I could just use option 2 only.

So am I missing something, or are these my only options?

Answer 1

I would go with option 1. I think it’s quite reasonable for your project to refer to everything on which it depends, even if these dependencies can sometimes be indirect.

It also seems to be the easiest option for me - and one that is suitable for Visual Studio to view the code dependencies that your application needs ... so that everything Visual Studio does with these dependencies should just flow naturally and not have think about it at every stage.

EDIT: Have you considered using NuGet as an alternative? That way, you only express the dependency on X in your dependencies of the NuGet project, but he would “know” that it depends on Z. I believe that all this just works ... You should be able to do this, even if it internal projects, as you can install your own NuGet source, not a public repository.