NuGet package for RProvider 1.0.1 broken about rprovider HOT 15 CLOSED

This started happening, on some machines, when I switched to referring to RDotNet via the NuGet package. I believe the fundamental issue is that when a type provider has dependencies, the IDE/compiler only look in the same directory as the type provider assembly (and the same directory as the compiler/IDE) for those dependencies. For relatively obvious reasons, it doesn't look in the other NuGet package directories. Once compiled, it would all work OK because all the binaries get copied to the bin/Debug directory, but it never gets that far because the compiler cannot initialize the type provider.

Sergey wrote a post-install script for RProvider which copies over the R.Net assemblies, but oddly NuGet seems to pass different values for install directories depending on what machine it runs on. So for some machines it works.

Since I published 1.0.1 R.Net has also been updated to v1.5.5.0. So this might look like a version mismatch, but I don't think it is (or at least, it is a version mismatch as well as a dependency problem!)

Haven't had time to figure it out yet because of other commitments, but I will ask @tpetricek to do so today!

from rprovider.

This is version mismatch, RProvider.1.0.1 uses R.NET.1.5.4 and RDotNet.FSharp.0.1.2.

from rprovider.

It might be, but on my machine it never gets as far as a version mismatch. fuslogvw shows where it is probing for assemblies and it doesn't look in the R.NET directory so doesn't find the assembly at all.

Now, once that is fixed, we might have a version mismatch too. If that is the case, then I don't understand how NuGet package dependencies are ever supposed to work. The nuspec specifies a dependency on R.NET 1.5.4. But since I published the package, R.NET has been updated to R.NET 1.5.5. When you add a NuGet reference to RProvider, it pulls down R.NET 1.5.5.

Are you suggesting that whenever a dependency is updated we need to re-publish RProvider?

from rprovider.

NuGet should download version specified in spec. I think that @mathias-brandewinder just manually updated R.NET and RDotNet.FSharp to the latest version from NuGet.

Yes, we need to update and republish RProvider whenever a dependency is updated.
For example canopy is updated after each release of Selenium.

from rprovider.

I didn't do anything manually - just created a library, and added the NuGet package for RProvider from the "Manage NuGet packages" in the solution explorer.

from rprovider.

Right- I get the same thing. Perhaps there is a way of specifying you won't accept newer versions?

from rprovider.

@hmansell, please publish on NuGet the RProvider v1.0.2 that is already in repository.
I hope that it is already contain all required fixes.

from rprovider.

I published and it seems to work for me. I remain concerned that it will break the next time R.NET is updated... I guess we'll find out whenever that happens!

from rprovider.

Looks like it's working on my end as well - which is great, because I am giving a short demo of the type provider at a R user group next week :)

from rprovider.

Looking at the NuGet versioning docs, I think that we might be able to require specific version of R.NET by using square brackets around the number:

<dependencies>
  <dependency id="R.NET" version="[1.5.5]" />
  <dependency id="RDotNet.FSharp" version="[0.1.2.1]" />
</dependencies>   

Not sure if this has any unfortunate implications - it might cause a compatibility issue if someone needs a different specific version of R.NET for some reason... but I don't think that's too likely.

from rprovider.

Ah, interesting. Also, I have a feeling this only affects us because
R.NETis signed. I believe the versioning check at load time happens
only for
strongly named assemblies.

On Wed, Sep 25, 2013 at 11:39 PM, Tomas Petricek
[email protected]:

Looking at the NuGet versioning docshttp://docs.nuget.org/docs/reference/versioning,
I think that we might be able to require specific version of R.NET by
using square brackets around the number:

Not sure if this has any unfortunate implications - it might cause a
compatibility issue if someone needs a different specific version of R.NETfor some reason... but I don't think that's too likely.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-25141840
.

from rprovider.

There are one more option that is possible for R.NET. Please read how this problem was solved in Json.NET - Json.NET Strong Naming and Assembly Version Numbers // cc @kos59125

from rprovider.

Or @kos59125 could get rid of strong-naming altogether.

On Fri, Sep 27, 2013 at 3:45 PM, Sergey Tihon [email protected]:

There are one more option that is possible for R.NET. Please read how
this problem was solved in Json.NET - Json.NET Strong Naming and Assembly
Version Numbershttp://james.newtonking.com/archive/2012/04/04/json-net-strong-naming-and-assembly-version-numbers.aspx// cc
@kos59125 https://github.com/kos59125

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-25271774
.

from rprovider.

Why do you need it signed? Do you have to sign the RProvider too?

On Oct 1, 2013, at 2:11 AM, Sergey Tihon [email protected] wrote:

Strong-naming is useful, otherwise I will have to sign it manually :)

—
Reply to this email directly or view it on GitHub.

from rprovider.

I use it from SharePoint and need to deploy it into GAC.
Sadly we do not use RProvider in production code - it is primary C#.

from rprovider.