Can't install Redis-64 NuGet package with NuGet 3.1

[breyed]

The Redis-64 package doesn't work on VS2015 with NuGet 3.1.60724.766. The problem seems to be that this version of NuGet doesn't support solution-level packages. As a workaround, I tried installing Redis-64 on a project, but it fails with this error:

Could not install package 'redis-64 2.8.2101'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Similar errors occurs for any .NET Framework version that the project is configured for.

[enricogior]

Hi @breyed,
the error you reported is logged when you run Install-Package Redis-64 from the Package Manager console?

[breyed]

The same error occurs whether I run from the Package Manager Console or the GUI.

[enricogior]

@breyed I don't have a machine with VS2015 yet (working on it) in the meanwhile can you please explain to me what you need to achieve adding Redis to the VS solution so that I might find a workaround to unblock your work?
Thank you.

[breyed]

I have a workaround for now. I dropped a copy of the redis .exe into the solution, rather than use the NuGet package. It's much less elegant, though.

Ideally, there is some way to add a package at the solution level that I didn't notice. This seems unlikely, however. I had the package there before I upgraded. Then just before upgrading, I wiped my workspace and did a fresh get from source control (so there was a reference to the package, but not the package itself). When I built, the NuGet 3.1 package restore seemed to ignore the .nuget\packages.config folder entirely. I tried adding the package at the solution level from the UI and command line, but both ways seemed to require a project.

The next best option would be to make the package project-friendly - somehow tell NuGet that it's compatible with any .NET version, or .NET 4.x, or whatever works. I don't know how to do that off hand, though. Looking at some other NuGet packages, it seemed to be inferred from the DLLs. I hope that's not the only way. It would be a shame to have to add a dummy DLL and have it be referenced by a project just to make NuGet happy.

[breyed]

Perhaps the right answer is to deprecate the Redis-64 package and aim towards NPM instead. The new model in VS2015/ASP.NET5 is this:

• NuGet: Server libraries
• Bower: Client libraries
• NPM: Tools (gulp, uglify, gulp-webserver, etc.)

Redis best fits into the NPM bucket. It's similar to a web server, since it is a run-time, not design-time binary.

[cybermaxs]

Redis-64 is a solution level nuget package and Solution-level packages were deprecated since Nuget 3.0 and VS 2015 (NuGet/Home#522). It's also impossible to install this package on a csharp project because of this.

Why do I need to install it ? In my case, it's just because my project contains integration tests relying on a local redis server.

Distributing redis-64 via a nuget package that we can't install via nuget is not pertinent for me.

Opencover has the same issue (OpenCover/opencover#315), you can use this fix for redis-64

[enricogior]

Hi @cybermaxs,
thanks you for reporting the issue, I agree it needs to be fixed, but it will take some time since there are some more urgent work items in the pipeline. We welcome the community contribution to improve the Redis on Windows experience, so feel free to submit a PR if you like.
Thank you.

[cybermaxs]

Hi @enricogior,

I will be happy to contribute but correct me if I'm wrong, all the nuget stuff is not included in this repo or not visible.

[enricogior]

@cybermaxs
the nuget stuff is located here:
https://github.com/MSOpenTech/redis/tree/2.8/msvs/ReleasePackagingTool
and here:
https://github.com/MSOpenTech/redis/tree/2.8/msvs/setups
the ReleasePackagingTool is used to generate the .nuspec file from a template setting the version number (it's also used to create the .zip file that is uploaded to the github release).
We currently use powershell scripts to:

• downloads the binaries from the github release(PullBinaries.ps1),
• sign the the binaries
• create the package (CreatePackages.ps1)
• and finally to push the package (PushPackages.ps1).

The script to sign the binaries is not included in the repo, so don't worry about it.
Feel free to create a complete new sub project if you prefer to start from scratch instead of making changes to the existing stuff.
If you need any other info, please let me know.
Thank you.

[cybermaxs]

@enricogior Ok, the fix is quite simple and I've submitted a PR

[enricogior]

@cybermaxs,
that's great!
It will be part of the upcoming 2.8.22 release.
Thank you very much :)

[enricogior]

@cybermaxs,
we just released v2.8.2104 that includes your fix.
Thank you.

[breyed]

Great news. Looking forward to the updated NuGet package.

[enricogior]

@breyed, @cybermaxs
closing the issue since the 2.8.2104 package is now online and works with NuGet 3.x.
Thank you.