packages cannot depend on packages that target projects.

Jun 9, 2011 at 10:16 PM

Well I'm completely perplexed at what this is. I've seen the workitem http://nuget.codeplex.com/workitem/595 that seems to be related to it, but it doesn't seem to be entirely accurate as I'm not sure why it would occur to me.

The Client.MVC.nupkg contains web.config.transform and nothing else, the Client.MVC.nuspec contains a dependency to Client.nupkg.

The Client.nupkg contains 1 dll and 1 pdb file in the lib\net40 folder, the Client.nuspec contains a dependency to Core.nupkg.

The Core.nupkg contains 1 dll and 1 pdb file in the lib\net40 folder, and nothing else, and no dependencies.

I created a new MVC3 Internet application as an entirely new solution, pulled up the package manager console. Set Package Source to my network location source (all Client.nupkg, Core.nupkg and Client.MVC.nupkg are in there) then I run

Install-Package Client.MVC3
'Core (≥ 1.0 && < 2.0)' not installed. Attempting to retrieve dependency from source...
Done.
Install-Package : External packages cannot depend on packages that target projects.
At line:1 char:16
+ Install-Package <<<<  Client.MVC3
    + CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand

Coordinator
Jun 10, 2011 at 12:07 AM

Does your Client.Mvc.nupkg include web.config.transform in the Content folder?

Jun 10, 2011 at 12:10 PM
Haacked wrote:

Does your Client.Mvc.nupkg include web.config.transform in the Content folder?

From the Client.MVC nupsec

<files>
    <file src="tools\**\*.*" target="tools" />
    <file src="**\*.transform"  />
  </files>

That would place it in the Content folder correct? or do I actually need to do target="content" ?

Developer
Jun 10, 2011 at 12:39 PM

Did you look at the resulting package to see if it ended up in the content folder? (You do have to specify content unless it was already in there before the recursive copy).

Jun 10, 2011 at 12:48 PM
dfowler wrote:

Did you look at the resulting package to see if it ended up in the content folder? (You do have to specify content unless it was already in there before the recursive copy).

Changing  <file src="**\*.transform"  /> to <file src="**\*.transform" target="content" /> seemed to do the trick. What's the difference between content and not content though?

Developer
Jun 10, 2011 at 12:53 PM

From our docs (http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#From_a_convention_based_working_directory)

  • tools - The tools folder of a package is for powershell scripts and programs accessible from the Package Manager Console. After the folder is copied to the target project, it is added to the `$env:Path (PATH) environment variable.
  • lib - Assemblies (.dll files) in the lib folder are added as assembly references when the package is installed.
  • content - Files in the content folder are copied to the root of your application when the package is installed.

A package that doesn't have anything that applies to a project is considered (external / solution only) and those can't depend on packages that do apply to projects.

Jun 10, 2011 at 1:08 PM
Edited Jun 10, 2011 at 1:12 PM
dfowler wrote:

From our docs (http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#From_a_convention_based_working_directory)

  • tools - The tools folder of a package is for powershell scripts and programs accessible from the Package Manager Console. After the folder is copied to the target project, it is added to the `$env:Path (PATH) environment variable.
  • lib - Assemblies (.dll files) in the lib folder are added as assembly references when the package is installed.
  • content - Files in the content folder are copied to the root of your application when the package is installed.

A package that doesn't have anything that applies to a project is considered (external / solution only) and those can't depend on packages that do apply to projects.

It might be too late now, but it seems like the content folder should be the default, and that another ancillary folder similar to the purpose of tools would house nonproject stuff.

How often would someone ever want to use the noncontent folder, 2%, 3% of the time? You're probably going to get questions like mine from now to infinity with this structure.

Coordinator
Jun 10, 2011 at 4:16 PM

Actually, 99% of the time folks are using the lib folder, which is a non-Content folder.

If we made the root, content, then there’d be ambiguity if you had a lib folder within the content folder. Or a tools folder within the content folder.

Also, there are cases where you want content in the package that’s not added to the project. That’d be difficult if we didn’t have the structure we have today.

Jun 11, 2011 at 4:34 AM

I wonder if we should add some smart in the tool to detect some common errors and display a warning. e.g. in the case above, having a .transform file at the root of the package is almost certainly a user error, and displaying a warning might save users a lot of headaches. It can't catch all the user error cases, but catching most of them would be enough of a worthy goal.

Jun 13, 2011 at 12:42 PM
Edited Jun 13, 2011 at 12:44 PM
Haacked wrote:

Actually, 99% of the time folks are using the lib folder, which is a non-Content folder.

 If we made the root, content, then there’d be ambiguity if you had a lib folder within the content folder. Or a tools folder within the content folder.

 Also, there are cases where you want content in the package that’s not added to the project. That’d be difficult if we didn’t have the structure we have today.

I meant specifically in regards to the "unnamed folder" vs content. But on the topic of lib, how often would a person ever want their assemblies to end up in the unnamed folder vs the lib folder? < 1%?

davidebbo wrote:

I wonder if we should add some smart in the tool to detect some common errors and display a warning. e.g. in the case above, having a .transform file at the root of the package is almost certainly a user error, and displaying a warning might save users a lot of headaches. It can't catch all the user error cases, but catching most of them would be enough of a worthy goal.

This could certainly be a happy medium. It really doesn't seem like the root folder does anything except add confusion, but atleast with some tooling assistance and getting a warning message could go a long way to overcome that.

IMO I think being very explicit over this will be a global good for nuget, I think it would make most sense that every folder requires specific targeting and to not have a "fall back". A fall back of "target folder is not supplied" and it breaking the packaging would be optimal to me.

Jun 13, 2011 at 3:21 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.