7
votes

Background: I have two assemblies called "A" and "B". ""A" references "B". "A" also references some additional dll's (Microsoft.Enterprise Library.Data and Microsoft Enterprise Library.Common ) that I think should be packaged in the nupkg.

I believe my nupkg package should contain the assembly output from "A", "B" and the two "Microsoft Enterprise" assemblies so that when someone installs my package it will give them a direct reference to the Assembly "A" and the other three assemblies would be available (but not directly referenced, so that their app would run. What is the correct way of packaging the non references dlls?

Attempt #1: Packing all required dll's in a \net35 folder According to the NuGet documentation regarding the "references" element "If this element is omitted, then the usual behavior applies, which is to reference every assembly in the lib folder."

So, I assume that by using this element it will only include the assemblies specified as references. This does not seem to be the case if I also use a "file" element <file src=*.dll" target="lib\net35" />. If I have an element like this that copies all dll's to the package it results in the assembly that implements this package to reference ALL the assemblies in the \net35 directory. This is not what I want to do. I expected some magic that only the assembly specified in "references" would be an actual be referenced and all the others would remain in the exploded \packages folder and the app would work since all the dlls are located in the same directory. Maybe I'm incorrect....

Attempt #2 Adding as content to project If I place the unreferenced assemblies into \content\lib instead of lib\net35 when packaged this creates a \lib folder in the project and directly dumps the \content\lib dlls into that project which then forces us to check them into source control. This works, compiles and runs as I want but, I really don't want these stored in the \lib folder of the project.

I am looking for a solution where the project gets the references to "A" and can still run with the to other required assemblies co-located but not directly referenced. It seems like Attempt #1 is the correct path but maybe there is a bug?

FYI, I entered this as a issue with NuGet directly to see it that team has an answer as well.

2

2 Answers

4
votes

This was a bug introduced in Nuget 2.1 and was later fixed in Nuget versions 2.2 which was released in December 2012.

Using Attempt #1 in original posting now works correctly.

0
votes

I don't think your "Attempt 1" is going to work in practice. If you only reference "A". when you build your package, only "A" will be copied (by default) to the output directory. Then, when you distribute the application, only "A" will exist causing errors.

You should have references to all DLLs to make your application run (or come up with another solution that will automatically copy the referenced DLLs to the output directory, but I'm not sure there is much value in not specifying the reference directly). Since you only have a few DLLs, it is probably best to just leave out the references section so that all of the DLLs are referenced automatically from the lib folder.