Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build omits transitive dependencies #2134

Closed
optical opened this issue Feb 2, 2017 · 6 comments
Closed

Build omits transitive dependencies #2134

optical opened this issue Feb 2, 2017 · 6 comments

Comments

@optical
Copy link

optical commented Feb 2, 2017

I'll just preface this issue by noting that I suspect this isn't a paket issue, but I am hopeful that someone from Paket might be able to recommend the correct place to post this, or provide an explanation or solution

Description

I have setup a trivial sample project using paket. Here we have a console application and a class library which the console depends on. The class library in turn depends on Microsoft.VisualStudio.Threading ~> 14.1.131. This has a transitive dependency on Microsoft.VisualStudio.Validation (>= 14.1.111). When paket resolves this, I end up with Theading at 14.1.131 and Valdiation at 15.0.82 - which all seems fine based on the constraints.
When I build the project, the bin directory for my class library contains both the threading and validation dlls as expected, however the console application only contains the class library and the threading dll. If we then run the console application we end up with an exception because Validation cannot be found, provided it isn't in the GAC. There are no warnings or errors emitted during the build.

I've run the build with the highest verbosity level and haven't been able to pinpoint where something might be going wrong. From what I can tell when building the console application it fails to recognize that Validation V15 is a dependency from the class library, instead its noting that Threading was built against V14 of validation. It however cannot find the V14 library locally and instead finds it in the GAC, which doesn't result in copying it locally. It should really however be trying to deal with V15 I'd have thought. If you then take the resulting build and run it on a machine without Threading in the GAC, it will crash.

If I manually add a binding redirect within the console application, it will work correctly. But it seems like there should be a warning or recommendation here to add that for me? I have AutoGenerateBindingRedirects set to true in the csproj's to try coax that behavior, to no avail

Here is an example build log

If anyone could provide some insight into this it'd be much appreciated, currently I am thinking that I need to switch from Max to Min resolver strategy within paket to avoid this happening in the future, but that doesn't really explain why this is happening without any warnings or errors.

Repro steps

  1. Download the project here

  2. Run the bootstrapper

  3. Run paket install

  4. Build the solution

Expected behavior

V15 of the Validation library to be present within the Console applications bin folder

Actual behavior

No version of Validation is present within the bin folder

Known workarounds

Changing the resolver strategy to min will prevent paket from fetching v15 of validation.
Manually adding a binding redirect for V15 will copy the library over.

@isaacabraham
Copy link
Contributor

Just tried. I don't actually get any errors with the app when I run it, although I did see the same behaviour that you observed i.e. no validation package is copied. As you observed, copying across a BR manually fixes the problem (which surprised me, I must admit).

Some other observations: -

  1. The lock file in the sample project is out of date compared to the dependencies file. I don't know why that is though.
  2. Paket has binding redirects support built in which currently isn't turned on for your project (add redirects: on to the .dependencies file). Unfortunately even turning that on does not fix it.
  3. You can work around this by adding the a paket.references file to the console app so that it gets the project added explicitly (which then does get the binding redirect added by Paket).
  4. As an aside, when I then removed the paket.references file, the BR was not removed.

BTW - you don't need to call the references .paket.references - just paket.references will do fine :-)

@isaacabraham
Copy link
Contributor

OK. I think I know what the issue is - you don't have a paket.references file in the console project. If you add into the same folder as the Console app - even if it's empty - then paket will realise that it needs to add BRs to the config file in there.

@optical
Copy link
Author

optical commented Feb 7, 2017

Interesting find. Unfortunately in my usecase I can't use paket within the Console project, we're using Nuget there. The reasons for this are complex unfortunately but I can explain if its really required. I've gone ahead and switched to using pessimistic resolution strategies in paket to avoid this situation for now.

It seems to me that this is likely an msbuild issue though, or is it genuinely pakets responsibility to be adding those BRs into the console project?

@isaacabraham
Copy link
Contributor

Hang on - so you're using paket for the class library and nuget for the console application? If that's the case, I have no clue why this is happening but yes, it's either a nuget or msbuild issue.

I'd suggest we close this.

@optical
Copy link
Author

optical commented Feb 7, 2017

I'll try dig into this a little more in the next couple days. I don't think the fact that our actual application is using Nuget is relevant, because there is no overlap between the dependencies were using. This is why the demo solution has the same issue.

I'll come back and update once I've got some more details. Will try experiment with Nuget to force it to use V15 of validation and V14 of threading, if at all possible. This would at-least rule paket out entirely.

@isaacabraham
Copy link
Contributor

Closing, lack of activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants