"Assembly outside lib folder" warning and packages including MSBuild Tasks

[augustoproiete]

Since NuGet 2.5 we can leverage the automatic import of msbuild targets and props files feature and add files such as {packageid}.targets and {packageid}.props to a special \build folder which are automatically added to the project file in which the nuget package is being installed, which is great.

However, when the .targets file uses custom MSBuild tasks that are shipped with the NuGet package, and we add these MSBuild tasks assemblies in the same \build folder, we get the following warning:

Issue: Assembly outside lib folder.
Description: The assembly 'build\MyCustomMSBuildTasks.dll' is not inside the 'lib' folder and hence it won't be added as reference when the package is installed into a project.
Solution: Move it into the 'lib' folder if it should be referenced.

Based on the the warning message, this seems like a bug. Given the assembly should not be referenced, it does not belong in the \lib folder and (I think) the \build folder would be the right place for it, together with the .targets file that uses it. The \tools folder would be another option, but we get the same warning, so same issue.

Would you agree this is a bug? If yes, than maybe the \build folder should be excluded in the MisplacedAssemblyRule check. Happy to send a PR to fix this.

If this is not a bug, then what would be the recommendation?

The only workaround at the moment (that I know of) is to have the custom MSBuild Tasks assembly in the lib folder, and then use the <references> metadata in the nuspec to be explicit about the assemblies to be referenced and prevent the custom MSBuild Tasks assembly to be referenced in the project.

[rrelyea]

We'd love to see NuGet pack stop warning when it is in the build folder. Yes, please send a PR.

[jkonecki]

May I suggest content folder is excluded from warnings as well?

[augustoproiete]

@jkonecki Interesting. Could you give an example of a scenario where you have an assembly inside the content folder?

Assuming your scenario makes sense, I'm wondering if it still makes sense to add exceptions, or if we shouldn't just remove the validation rule altogether.

[jkonecki]

I'm using NuGet to package applications that will be deployed with Yams.

According to docs from NuGet.org:

Think of the content folder as of the target application, so if you want the package to add an image in the application's /images folder, place it in the content/images folder of the package.

That's why I place all assemblies in content folder. They could be placed in the root of the package as well, with the same warning.

With NuGet being used as a format for application packaging (OctoPack) I think the warning is a bit misleading and not very useful.

[SimonGustavsson]

@caioproiete In my case, I have a .NET application where I pull in a package I've made that includes a .NET wrapper around a native API. So the package contains the native DLL too (Which I've put in the content folder, because it can't be added as a reference to a .NET project. It's just content that gets copied to the bin directory when the application builds). Seems like a reasonable thing to do.

[mjamro]

@caioproiete For example when you want to add some sort of an external tool (.exe + dlls) to the package, which will later be used by calling the exe file, not by referencing it. You do not need to reference the dlls in your project in that case.

[ap0llo]

Is this issue still open? I tried to reproduce it with the latest version of nuget.exe but it did not seem to produce a warning for assemblies in build

[josteink]

Seconding packing for Octopus Deploy. This warning is really annoying and is causing lots of warnings in my build.

It would be nice if NuGet offered a way to silence this warning when the user knows what he is doing.

[petsuter]

Glancing at the source suggests this is still broken in the NuGet V2 repo but fixed in the NuGet 4.0+ repo since this commit maybe?