4

Say I have a Visual Studio 2015 solution with two projects, MyApp (.NET) and MyLib (Portable--targeting .NET 4.6 and UWP 10). It compiles and runs fine.

Then I add any NuGet package to MyLib--could be anything, but let's just pick Rx-Main just as an example. I add a simple line of code in a MyLib class that makes use of an Rx type.

Now MyApp will crash upon startup with a FileNotFoundException citing the nuget package dll. By adding the same NuGet package to MyApp solves the issue.

Why is it necessary to add the NuGet package to the application project as well?

If MyLib was a normal .NET project this would not be necessary.

EDIT Some clarification is needed...

In a standard .NET class library project, all the NuGet packages show up as individual DLLs under References:

enter image description here

They each have a dozen properties that can be edited in the Properties window, including Copy Local:

enter image description here

In a PCL project, under References, the NuGet packages have no properties whatsoever, and no way to have them copied to the output directory.

enter image description here

enter image description here

There are at least two problems with this situation:

  1. It only rears its ugly head at runtime (FileNotFoundException), not compile time.
  2. Now every client of that PCL project is forced to deal with all the dependencies of that PCL, whereas before it was cleanly transparent.
BCA
  • 7,776
  • 3
  • 38
  • 53
  • http://stackoverflow.com/questions/20280717/references-from-class-library-are-not-copied-to-running-project-bin-folder, http://stackoverflow.com/questions/15816769/dependent-dll-is-not-getting-copied-to-the-build-output-folder-in-visual-studio. The executing application will always need to be able to find the assemblies that your referenced projects reference (as soon as their types are to be used), whether those references are project references or assembly references (where the latter are managed by NuGet or not, does not matter). – CodeCaster Nov 10 '15 at 22:40
  • 1
    @CodeCaster, why is this not a requirement for a standard .NET library project? I realize that for those, each DLL has its `Copy Local` property set to `true` by default... but how can the same be achieved for those blue-icon NuGet package references? – BCA Nov 11 '15 at 00:59
  • I'm not sure what you're asking. At runtime, the runtime must be able to load all required assemblies. Whether those were packed in (dependencies of) NuGet packages does not matter. – CodeCaster Nov 11 '15 at 09:13
  • Learn more about the crash such as exception message and call stack. That can tell. – Lex Li Nov 11 '15 at 10:34
  • @CodeCaster: please see EDIT – BCA Nov 11 '15 at 13:38
  • Hard to imagine this failure mode, tends to only go wrong when a library uses reflection. MSBuild copies dependent DLLs but it will not complain when it can't find them. Basic checks are verifying that the DLL(s) indeed got copied to the build directory of the PCL library project. And running ildasm.exe and looking at the manifest for .assembly directives for the Nuget assemblies. Troubleshoot by digging through the diagnostic MSBuild trace. – Hans Passant Nov 11 '15 at 13:44
  • @HansPassant, no need to imagine; create a new VS solution, follow those basic steps, and you'll see what I'm describing (unless there's something screwed-up with my VS or NuGet installation) – BCA Nov 11 '15 at 14:11
  • 2
    Did you ever solve this? – slinzerthegod Dec 31 '15 at 12:50

0 Answers0