Paket removes references which are under user control

[Stift]

Description

References which are under user control should not be removed by Paket. Paket removes always references and let our build fail

Repro steps

We have a silverlight class library project which we use for testing. We add e.g. System.Net to that library and want to use that in our code. When we add the nuget dependency Microsoft.Bcl.Async then System.Net is removed because the for net40 this is specified as reference.

Expected behavior

We should be able to have control over that reference. But Paket always removes references. Also specifying <Paket>False</Paket> does not help.

Actual behavior

We always lose the references after a paket run.

Known workarounds

none. Use paket 2 as this behaviour seems new in Paket 3.

Related information

N/A

[forki]

Argh. Please create a repro sample and temporarily downgrade to 2.x

This is related to the fact that --hard is now the default. But it should
not remove manual references that are marked with paket = false.
On Jun 22, 2016 10:21 AM, "Christian Fiebrig" [email protected]
wrote:

Description

References which are under user control should not be removed by Paket.
Paket removes always references and let our build fail
Repro steps

We have a silverlight class library project which we use for testing. We
add e.g. System.Net to that library and want to use that in our code. When
we add the nuget dependency Microsoft.Bcl.Async then System.Net is
removed because the for net40 this is specified as reference.
Expected behavior

We should be able to have control over that reference. But Paket always
removes references. Also specifying False does not help.
Actual behavior

We always lose the references after a paket run.
Known workarounds

none. Use paket 2 as this behaviour seems new in Paket 3.
Related information

N/A

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1746, or mute the thread
https://github.com/notifications/unsubscribe/AADgNIMlhjIinSWPb7GkyxVWpWu9h_fLks5qOPCQgaJpZM4I7hM-
.

[Stift]

Ok. Took me a while to have a minimal repro to understand what happens.

So, if you take the repro here , then first is fine when you do .paket\paket install. But when you set <Private>True</Private> on the reference System.Net in the SilverlightClassLibrary.csproj and run .paket\paket install again, then it removes the dependency.
The check should be softer. In the reference-tag the include-attribute it could also contain a specifc version or sometimes also a subnode with a hint path. All these should be ignored by paket and let as-is because the user controls these.

[forki]

is a0d66a7 the change you meant? It's still keeping things green

[Stift]

yes. Exactly that change makes it fail.

[forki]

according to the integration test it keeps it. can you please check again?

[Stift]

you need to add the dependency microsoft.bcl.async v1.0.168

[Stift]

this is the one which references system.net for net40

[forki]

ok. I can reproduce. It moves it down to it's own Choose nodes (which is expected).

That said. If I change it to

<Reference Include="System.Net" >
  <Private>True</Private>
  <Paket>False</Paket>
</Reference>

I'd expect it to stay. Unfortunately Paket still thinks it can take over control. I consider this a bug

[Stift]

The problem that I see in that case, that System.Net is only defined for net40. Do you think in this case it should take the control away? It takes a lot of knowledge and investigation to find this out. For general developers it's really hard.

[forki]

it's what the package specifies.
Anyways. a fix is underway that allows you to add paket = false

[Stift]

I agree with that, but still it feels like paket steals this!

[forki]

I really see it as: we fix it according to the package specification. But
we allow you to know better.
On Jun 22, 2016 1:05 PM, "Christian Fiebrig" [email protected]
wrote:

I agree with that, but still it feels like paket steals this!

https://camo.githubusercontent.com/223ca839418af93739a63949f550ee069cd29448/687474703a2f2f692e67697068792e636f6d2f5653694e66736c38564952496b2e676966

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1746 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADgNN8gci3Nlwk-5lp_wzUD4J70GATQks5qORcEgaJpZM4I7hM-
.

[Stift]

I understand this. At least the fix gives me a way to work with. I don't have a better solution for now. The only thing that I can think of, is also to define my other dependencies.

BTW, thx for the immediate reaction.

[Stift]

I tested it and it seems to work, but a <Paket>False</Paket> is not needed. Is this is intended by you?

[forki]

yeah. there was another bug(?) in exactly the same line. If you add "private" then it thought it was not a framework reference. But your sample shows that this assumption was wrong

[forki]

anyways marking it with paket = false is a safe bet

[Stift]

ok. thx.