Well I think we have 3 scenarios here:
- Designer: You have a set of assemblies that should not be referenced, and should not be copied to bin.
- xUnit: You have a set of assemblies that should be referenced, but from a directory other than lib.
- Runtime only assemblies: You have a set of assemblies that should not be referenced, but should be copied to bin.
For me VS already handles correctly cases 1) and 3) : if the library referenced requires additional assemblies located on the same lib folder, then these dependencies are copied along with the main assembly when compiling your project. But if the
assembly is not referenced at all (as it's the case for .Designer assemblies), VS will never copy them to the output directory.
A single attribute in the <file /> element could handle all of these : for example "reference" which defaults to true when target="lib" and false for other targets. (It will allow
to handle case 2) also l <file src="xUnit.dll" target="tool" reference="true" />).
It will allow to deploy additional assemblies in the lib folder to provide optional features that the developer could reference directly beside the main references.
NuGet will only use this attribute value to choose if the library must be added as a reference in vs or not (+ the extension type in case of <file src="MyLib.pdb" target="lib" />)
Also, should the package allow to specify the "Copy Local" and "Specific Version" property from the referenced assembly ? I don't know. For me it doesn't seems necessary. It could help to handle cases where you want to add the library as a valid reference
but doesn't want it to be deployed.