Nuget reference adds a nuget dependency #33

johncrim opened this Issue Jan 19, 2013 · 8 comments


None yet
4 participants

This is a fantastic tool - thank you! But it seems wrong to require a reference to the plugins in use.

To provide more detail, when I install the PropertyChanged.Fody NuGet package, it adds a reference to my csproj, and a reference to my packages.xml. The addition to packages.xml makes sense (it needs to be download to build), but the new reference in my csproj should not be required. Due to that reference, the nuget package build from my project transitively has a reference to PropertyChanged.Fody; which means that any projects that use my project will also download and depend on PropertyChanged.Fody. It seems to me this shouldn't be necessary, since PropertyChanged.Fody is a build-time tool, and there is no actual binary reference (please correct me if I'm wrong).

If you remove the from your *.csproj file, the weaving still works, but unfortunately NuGet doesn't have a way to exclude the package as a transitive dependency for other projects ( ).

I think the right fix is to modify the nuget package so it puts the DLLs in a /tools subdir instead of a /lib subdir. After all, this is a tool, and not a dependency. I'd be happy to take this on for at least one of the plugins to ensure that this will work.


SimonCropp commented Jan 19, 2013

if you change it to a Solution level package, to achieve "no nuget dependency", how would you edit the FodyWeavers.xml as part of the nuget install since install.ps1 doesnt run for solution level packages

@johncrim have you looked at your compiled assemblies in Reflector or dotPeek? I think you'll find that MSBuild trims out unused references at build time.

Yes, I looked at the compiled assembly in dotPeek, and I see that there's no dependency on PropertyChanged.dll - which is what I would expect. However, the NuGet package still has a dependency on PropertyChanged.Fody .

I'm not suggesting changing this to a Solution level package, it's appropriate that it be a project dependency, since different projects will have different IL weaving needs. I was suggesting that within the .nupkg, the PropertyChanged.dll not be under a /lib dir, but it be under a /tools dir, so it won't get included as a NuGet dependency (in theory - I haven't tested this out, but it seems like the only mechanism that NuGet has for identifying something as a build-time tool instead of a run-time lib). More info:

For example, say I have library project Foo.csproj, which uses PropertyChanged.Fody, and which builds a NuGet package. Then I have web app Bar.Web.csproj that has a NuGet dependency on Foo. After adding PropertyChanged.Fody to Foo, and creating my new NuGet package, I can't update Bar.Web.csproj to use my new build of Foo. I get:

Could not find FodyWeavers.xml in this project. Please enable Fody for 
this projet

Install failed. Rolling back... 

and then the NuGet packages are rolled back to how they were before.

The reason for this is that given the current implementation, PropertyChanged.Fody becomes a transitive dependency of Bar.Web.csproj. The Foo.nupkg contains a Foo.nuspec, which contains this block:

      (any other dependencies)
      <dependency id="PropertyChanged.Fody" version="" />

If I manually go in and remove the <dependency> element, then I can update Bar.Web.csproj using the new build of Foo.

As I said, I'm thinking that moving the location of PropertyChanged.dll within the PropertyChanged.Fody.nupkg from /bin/* to /tools would work (so that the transitive dependency is not included) - but I haven't done that b/c I assume that there's logic that requires it there.


SimonCropp commented Jan 22, 2013

If a package has no items in Lib it is considered a solution level packages and as such and install.ps1 wont run
So your proposal would fix one bug but another

Also I dont understand why you are asking me to change my tool to workaround a bug in nuget. Why dont I see your name here discussing with the nuget guys how to fix the real problem.

I wasn't aware of either of the defects in NuGet - I thought it was as designed - or at least a convention - use /lib for library dependencies, and /tools for tools. I've voted up the NuGet issues you pointed me to, and I'll add comments to them as well, and point them at this issue.

NuGet has potential, but it's been irritatingly buggy, and the design doesn't seem to clearly and cleanly address some common use-cases (it seems that they didn't take the time to examine and learn from Maven). I wasn't trying to create work for you, just pointing out a problem with the current NuGet package. As I said above, Fody is fantastic and I appreciate your work on it.

Given the current behavior, I'm unable to re-use the library that uses Fody. I can either (1) try to fix the bug(s) in NuGet, or (2) I can try to figure out how to use Fody without a NuGet dependency on it, or (3) I can create a patch for Fody so that the install.ps1 doesn't break nuget update if FodyWeavers.xml is missing. Do you have any recommendations? (1) sounds best (most value for everyone), but even if I find the fixes, they probably won't make it into the real NuGet build for a while.


SimonCropp commented Jan 24, 2013

Only thing I can think of is to write an msbuild task to run after the nuget is packaged and remove the dependency on anything *.Fody
Would not be difficult. it is only a zip file after all.


distantcam commented Jan 25, 2013

The common work-around for the NuGet issue is to include a dead file in content in the NuGet package, and then remove it in the Install script.

As for fixing the the generated NuGet package, you can fix it after the install as suggested, or what I do is have a hand made nuspec file to make packages from, and it has the correct dependencies already. I've found the generate-nupkg-from-project feature makes too many mistakes. Plus you can't specify things like licence, project url, etc. Using a nuspec file works much better.


SimonCropp commented Feb 5, 2013

I am closing this since it is a bug/missing feature in nuget.

And there is the simple workaround of hand crafting the nuspec file. This is what I do for all my nuget packages.

Sorry for any inconvenience this may cause.

SimonCropp closed this Feb 5, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment