added option to automatically generate nuget dependency list from target...

[keeger]

...ed packages. This is reflected in the NuBuildAutoGenerateDependencies property being set to true.

If NuBuildAutoGenerateDependencies = true (default) but a dependency list is specified in the nuspec file, the nuspec file wins, and no auto-generation is done.
Also updated Nuget.Core to 2.8, and pushed the version to 1.9.1

[lmagyar]

This solution has some issues (if I read the source correctly).

• it reads directly the project file as XML instead of using MSBuild's ProjectReference item
• it fills out dependencies tag but not the frameworkAssemblies tag (referenced assemblies except references from packages)
• it doesn't differentiate between targetFrameworks
• it doesn't compact the reference set to the minimal required (like NuGet does with PackageWalker)

I'm started to implement #41 with these considerations, it uses your NuBuildAutoGenerateDependencies property to be compatible with existing project files. My NuBuild version uses project flavor (ie. csproj files not nuproj files, but this is only for VS/NuGet), the NuPackage.cs and other files are compatible with the 1.x versions. I will publish it this week, but I want to test it on real projects.

[keeger]

• it reads directly the project file as XML instead of using MSBuild's
  ProjectReference item

I read the project file as xml to obtain the full path to the referenced
csproj file. This is so I can then open the packages.config file to read
dependencies. If ProjectReference can help with that, then i'm all for it.

• it fills out dependencies tag but not the frameworkAssemblies tag
  (referenced assemblies except references from packages)

I did not know this was required?

• it doesn't differentiate between targetFrameworks

I'm pulling the dependencies from the referenced projects, so the
targetFramework will be determined by that. I would think if the packages
are different by targetFramework, that there'd have to be seperate csproj's
to handle that? Maybe i just don't understand targetFrameworks correctly :)

• it doesn't compact the reference set to the minimal required (like
  NuGet does with PackageWalker)

I don't know how it does that. That'd be a nice feature.

On Wed, Feb 19, 2014 at 8:53 AM, lmagyar notifications@github.com wrote:

This solution has some issues (if I read the source correctly).

• it reads directly the project file as XML instead of using MSBuild's
  ProjectReference item
• it fills out dependencies tag but not the frameworkAssemblies tag
  (referenced assemblies except references from packages)
• it doesn't differentiate between targetFrameworks
• it doesn't compact the reference set to the minimal required (like
  NuGet does with PackageWalker)

I'm started to implement #41https://github.com/bspell1/NuBuild/issues/41with these considerations, it uses your NuBuildAutoGenerateDependencies
property to be compatible with existing project files. My NuBuild version
uses project flavor (ie. csproj files not nuproj files, but this is only
for VS/NuGet), the NuPackage.cs and other files are compatible with the 1.x
versions. I will publish it this week, but I want to test it on real
projects.

Reply to this email directly or view it on GitHubhttps://github.com//pull/49#issuecomment-35500394
.

[lmagyar]

To fill out frameworkAssemblies automatically, makes life much easier. :) Simply you don't need to edit frameworkAssemblies and dependencies in nuspec at all.

Yes, different targetFramework-s require multiple csproj-s to include/refer in NuBuild project. And yes, handling targetFrameworks automatically in frameworkAssemblies and dependencies is tricky, at least for me. :/