Support for Nuget

[Maciej Klemarczyk]

Support for https://www.nuget.org/ will be great feature. This is primary package manager for Visual Studio projects.

[Matt Smith]

Are there plans to have the Nuget integration work against Paket configs?

[Robert Reiz]

If nuget is integrated it should be a small step to Packet :)

[Robert Reiz]

Notes for myself.

Blog Post about Nuget API. No. It's not REST! :-(

http://chris.eldredge.io/blog/2013/02/25/fun-with-nuget-rest-api/

MetaData structure:

https://www.nuget.org/api/v2/$metadata

Index:

https://www.nuget.org/api/v2/Packages

[tiagoespinha]

Hi guys,

Is there any plan to bring support for NuGet packages any time soon?

We would very much like to use VersionEye but our code base is mostly C# and Node code, which means NPM packages and NuGet packages... support for NuGet is really essential for us.

Is this in the planning already?

Thanks, Tiago

[Robert Reiz]

Yes. Nuget support is coming this summer.

[tiagoespinha]

Great @reiz ! Really looking forward to it

[Timo Sulg]

Hi,

i let you know that i started to merge nuget parser to versioneye-core .

[Robert Reiz]

@timgluz Awesome. Let me know if you need more help.

[Robert Reiz]

The Nuget crawler is running now the first time on production. I guess it will need some changes, but somewhere next week we should have .NET Nuget support!

[Robert Reiz]

@timgluz After 7K packages the Nuget crawler died. I added some Exception handling and started it again.

[tiagoespinha]

@reiz any news on the new run of the crawler? Did it succeed?

[Timo Sulg]

@tiagoespinha Yes, it did - you can check results here: https://www.versioneye.com/csharp

I'm still working on Nuget and Paket parser and if everything goes well, then it should be done and reviewed end of next week.

[Robert Reiz]

@tiagoespinha @timgluz The initial crawl ist not not 100% finished, but the first results are already visible. And we need to work on the license recognition, because most NUget packages don't publish a license name, just a link to a license.

[Robert Reiz]

@tiagoespinha The first version of .NET support is online. We have now ~ 74K .NET packages at VersionEye and we support the monitoring of project.json and .nuspec files. Most of this work was done by @timgluz. Many Thanks for that.

This is still the first shot. Please contact us if something goes wrong.

[Jens Doose]

Maybe noteworthy: Only works with package specification in the "new" NuGet format with project.json and *.nuspec files and (according to the blog post) not with the "traditional" package.config. Converting a csproj from package.config to project.json: https://github.com/NuGet/Home/wiki/Converting-a-csproj-from-package.config-to-project.json

Andy by the way: the nuget file formats are missing in the list of supported file types on the "create by upload" page

[Robert Reiz]

Thanks @jdoose. Currently @timgluz is working on the package.config support.

[Timo Sulg]

Hi, @jdoose! Thanks for your feedback.

I'm not professional .net developer and i just followed Nuget specifications during the integration.

Is there official package.config documentation or specification? I checked couple of examples on Github and i'm not sure what is the correct way to specify dependencies:

<Dependency name="Starcounter">~2.1.284</Dependency> source

or

<package id="AspNetMvc" version="4.0.20126.16343" /> source

And how are version ranges specified in package.config? Nuget's or something else? Does package.config version "1.2.0" means "1.2.0 <= x " , like in Nuget or it means "1.2.0 == x"?

[Jens Doose]

Hi Timo,

I haven't found anything "official" about the packages.config-format. In our projects they all look like this:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="BuildTools.StyleCop" version="4.7.49.0" targetFramework="net40" />
  <package id="Simple.Data.Ado" version="0.18.3.1" targetFramework="net40" />
  <package id="Simple.Data.Core" version="0.18.3.1" targetFramework="net40" />
  <package id="Simple.Data.SqlServer" version="0.18.3.1" targetFramework="net40" />
  <package id="SlowCheetah" version="2.5.12" targetFramework="net40" />
</packages>

On the other hand I'd say it would be acceptable if only the new format is supported. The old one will go away eventually...

Plus: In VS it is pretty common that a solution contains quite a lot projects (~20 is not uncommon). I think it would be cool if a complete solution could be monitored instead of single projects. On the other hand that's probably a thing the web UI does not support yet...

[Timo Sulg]

ok, it looks simple enough to add. Are all the versions fixed? Or you can specify ranges too?

[Jens Doose]

As far as I know it only supports fixed versions. But I don't know for sure. At least I haven't seen anything else than the given notation above.

[Robert Reiz]

I just merged the pull request from @timgluz and deployed it to production. Now we should have support for packages.config as well. @jdoose Please test it with your files and let us know how it works for you. If it doesn't work like expected please open another ticket for that with all the details.

[Jens Doose]

One question to put it in context: on twitter you said, support für packages.config files is included. Is that correct? Is there a difference between GitHub crawling or uploading? Because uploading a package config (the one above) does not work: "ERROR: project file could not be parsed. Maybe the file is empty? Or not valid?"

[Robert Reiz]

Hi @jdoose. The package.config was missing here in this filer: https://github.com/versioneye/versioneye-core/commit/9aa6bacc0ffec38ab3da4c42244c842d6b5ddc4a. It's fixed now. I just uploaded a packages.config file and it worked for me. Please try again, it will work now :)