Question

So the problem is quite simple: My project references assembly X but not Z. But assembly X does reference assembly Z. Assembly Z updates somewhat frequently, so whenever I build my project, I’d like to get the latest version of Z as well.

So far I’ve come up with 3 options:

1. reference the assembly Z. This has the advantage of getting the new version, always. But it does pollute the references with something that isn’t strictly required in there.
2. Add a post-build event that copies the required DLL(s) from where they are updated. I think this is quite ok, until I need multiple different DLLs, which would make the script quite long and tedious to maintain.
3. Add the assembly Z as a resource and set copy to output to true. This one I would probably prefer, except that when I add the DLL to the project, visual studio actually copies the (then) current version in to the project, and there is no link to the original source. Thus, when the assembly is updated, this is not reflected in any way in my project. Unless I combine this approach with option number 2, but then I might as well just use option 2 alone.

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

Answer 1

I would go with option 1. I think it’s entirely reasonable for your project to reference everything it depends on, even if those dependencies can sometimes be indirect.

It also seems like the simplest option to me – and one which fits in with Visual Studio’s view of code dependencies that your app requires… so anything that Visual Studio does with those dependencies should just naturally flow, rather than you having to think about this at every stage.

EDIT: As an alternative option, have you considered using NuGet? That way you’d only express a dependency on X within your project’s NuGet dependencies, but it would “know” that it depended on Z. I believe it should all just work… You should be able to do this even if these are internal projects, as you can set your own NuGet source rather than the public repository.