Support group-specific dependencies #140

cdrnet · 2014-09-20T19:08:02Z

Project A has a dependency on B, which in turn depends on TaskParallelLibrary, but only for target platform .Net 3.5. TaskParallelLibrary is an indirect dependency only and not mentioned in paket.references or or paket.dependencies (but is mentioned in paket.lock).

The nuspec dependencies of B look like the following:

<dependencies>
    <group targetFramework=".NETFramework3.5">
        <dependency id="TaskParallelLibrary" version="1.0.2856.0" />
    </group>
    <group targetFramework=".NETFramework4.0" />
</dependencies>

With Paket v0.2.26, the following references are generated in A:

  <Choose>
    <When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v3.5'">
      <ItemGroup>
        <Reference Include="System.Threading">
          <HintPath>..\..\packages\TaskParallelLibrary\lib\Net35\System.Threading.dll</HintPath>
          <Private>True</Private>
          <Paket>True</Paket>
        </Reference>
      </ItemGroup>
    </When>
    <When Condition="$(TargetFrameworkIdentifier) == '.NETFramework'">
      <ItemGroup>
        <Reference Include="System.Threading">
          <HintPath>..\..\packages\TaskParallelLibrary\lib\Net35\System.Threading.dll</HintPath>
          <Private>True</Private>
          <Paket>True</Paket>
        </Reference>
      </ItemGroup>
    </When>
  </Choose>

The first one for v3.5 seems to be correct, but the latter should not be there, as it causes TaskParallelLibrary to be referenced in v4.0 and newer as well.

See: https://github.com/mathnet/mathnet-symbolics/blob/paket/src/Symbolics/Symbolics.fsproj

Does Paket not support framework-conditional dependencies at all yet or is this merely a resolver issue?

The text was updated successfully, but these errors were encountered:

cdrnet · 2014-09-20T19:24:08Z

Note that the nuspec reference is quite unclear if not wrong on what happens if multiple groups specify a compatible target framework. The behavior of NuGet itself is equivalent to the /lib/net40 style folders, i.e. the "best" fit wins and the others are ignored.

From the nuspec reference: "All dependencies inside a group are installed together if the target framework is compatible with the project's framework profile.". This could be interpreted in a way that all groups with a compatible target framework should be installed - and the current Paket behavior correct. However, that would make it impossible to restrict to specific versions only (= constraint) and is not how NuGet behaves.

cdrnet · 2014-09-20T19:33:49Z

Verbose Output:

$ paket install --verbose
Paket version 0.2.26.0
FsUnit 1.3.0.1 already downloaded
FSharp.Compiler.Service 0.0.44 already downloaded
MathNet.Numerics.FSharp 3.2.3 already downloaded
FParsec 1.0.1 already downloaded
Microsoft.AspNet.Razor 2.0.30506.0 already downloaded
MathNet.Numerics 3.2.3 already downloaded
FSharp.Core.Microsoft.Signed 3.1.1.1 already downloaded
FSharp.Formatting 2.4.4 already downloaded
MathNet.Numerics 3.2.3 already extracted
FsUnit 1.3.0.1 already extracted
Microsoft.AspNet.Razor 2.0.30506.0 already extracted
FSharp.Compiler.Service 0.0.44 already extracted
FParsec 1.0.1 already extracted
MathNet.Numerics.FSharp 3.2.3 already extracted
FSharp.Core.Microsoft.Signed 3.1.1.1 already extracted
FSharp.Formatting 2.4.4 already extracted
NUnit 2.6.3 already downloaded
NUnit.Runners 2.6.3 already downloaded
RazorEngine 3.3.0 already downloaded
TaskParallelLibrary 1.0.2856.0 already downloaded
NUnit 2.6.3 already extracted
NUnit.Runners 2.6.3 already extracted
TaskParallelLibrary 1.0.2856.0 already extracted
RazorEngine 3.3.0 already extracted
Installing to c:\Users\Christoph\Math.NET\mathnet-symbolics\src\Symbolics\Symbolics.fsproj
  - direct packages: [|"FParsec"; "FSharp.Core.Microsoft.Signed"; "MathNet.Numerics";
  "MathNet.Numerics.FSharp"|]
  - all packages: [|"FParsec"; "FSharp.Core.Microsoft.Signed"; "MathNet.Numerics";
  "TaskParallelLibrary"; "MathNet.Numerics.FSharp"|]
  - installing FParsec
  - custom nodes for FParsecCS ==> skipping
  - installing FSharp.Core
  - installing MathNet.Numerics
  - installing MathNet.Numerics.FSharp
  - installing System.Threading
Installing to c:\Users\Christoph\Math.NET\mathnet-symbolics\src\SymbolicsUnitTests\SymbolicsUnitTests.fsproj
  - direct packages: [|"FParsec"; "FSharp.Core.Microsoft.Signed"; "FsUnit"; "MathNet.Numerics";
  "MathNet.Numerics.FSharp"; "NUnit"|]
  - all packages: [|"FParsec"; "FSharp.Core.Microsoft.Signed"; "FsUnit"; "NUnit";
  "MathNet.Numerics"; "TaskParallelLibrary"; "MathNet.Numerics.FSharp"|]
  - installing FParsec
  - custom nodes for FParsecCS ==> skipping
  - installing FSharp.Core
  - installing FsUnit.NUnit
  - installing MathNet.Numerics
  - installing MathNet.Numerics.FSharp
  - installing nunit.framework
  - installing System.Threading
02.19s - ready.

forki · 2014-09-21T09:39:32Z

Does Paket not support framework-conditional dependencies at all yet or is this merely a resolver issue?

didn't know this stuff exists ;-)
will look into it.

cdrnet · 2014-09-21T09:56:02Z

Thanks!

Just noticed this is also used in the Octokit nuspec testfile where the dependency on Microsoft.Net.Http is skipped on .Net 4.5+ and .Net-Core 4.5+ but used in all other configurations. Might get ugly to map this with Choice/When in MsBuild.

forki · 2014-09-21T09:59:16Z

Might get ugly to map this with Choice/When in MsBuild.

it already is a big pain....

forki · 2014-09-21T10:02:49Z

boah. this thing is really really ugly.

bartelink · 2014-09-21T10:10:46Z

Related stuff at end of #68

forki · 2014-09-21T10:21:59Z

this is completely fucked up. and I don't even see a way to solve this with @ilkerde's strict mode.

cdrnet · 2014-09-21T10:22:27Z

Most cases where such monkey-patching is needed is bad packages not restricting their target platforms properly, so ideally this could be fixed there instead. But this is not always possible unfortunately.

forki · 2014-09-21T10:35:20Z

after think about this:

There is no way to do this without computing the whole installation model in advance. This will probably improve some other things too. But it will take a while.

So please manually edit to:

  <Choose>
    <When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v3.5'">
      <ItemGroup>
        <Reference Include="System.Threading">
          <HintPath>..\..\packages\TaskParallelLibrary\lib\Net35\System.Threading.dll</HintPath>
          <Private>True</Private>
        </Reference>
      </ItemGroup>
    </When>
  </Choose>

Notice I also remoded the paket flag. This will make the nodes for paket to not touch it again.

cdrnet · 2014-09-21T10:37:25Z

Yes, this will work for me as workaround. Thanks!

bartelink · 2014-09-25T08:24:06Z

It's interesting that there seem to be two ways of modelling conditional NuGet package dependencies -

either the .nuspec declares groups and then only adds a <dependency to a subset (the case you're talking about)
there's always a dependency, but sometimes it nulls itself out (the Microsoft.Net.Http model)

It seems the latter is more sustainable or downstream packages are not respecting the Law of Demeter (though it's tempting if System.Threading only needs to be shimmed in net35)

@cdrnet #145 and #146 address the two concerns you note re octokit

Base NuGet Lib Reference generation on Lib Folders #145 "Base NuGet Lib Reference generation on Lib Folders" deals processing the Microsoft.Net.Http nuget

Support (Conditional) Framework Assembly References #146 "Support (Conditional) Framework Assembly References" is a more exotic variant of the octokit:

<frameworkAssemblies>
    <frameworkAssembly assemblyName="System.Net.Http" targetFramework=".NETFramework4.5, .NETCore4.5" />
  </frameworkAssemblies>

@cdrnet How about renaming this issue to "support group-specific dependencies" (or calving a new issue and closing this)

<dependencies>
    <group targetFramework=".NETFramework3.5">
        <dependency id="TaskParallelLibrary" version="1.0.2856.0" />
    </group>
    <group targetFramework=".NETFramework4.0" />
</dependencies>

@forki (or @ilkerde) Can you explain what you mean by strict mode wrt this issue? (I'd like to understand it for #154). I've come across it in the docs but to be honest they didnt speak to me and I hence wasnt able to arrive a sufficient understanding to be able to verify whether it was explained wlll or whether I'm just missing a concept (or 3!)

cdrnet · 2014-09-27T09:11:30Z

@bartelink I don't quite understand how the mentioned Microsoft.Net.Http model works for specifying conditional dependencies (where I cannot modify the packages I depend on). How would I have to declare my dependencies in my nuspec in the following similar case (other than the dependency groups)?

On .Net 3.5 depend on FSharp.Core.4.3.0.0.Microsoft.Signed
Evereywhere else depend on FSharp.Core.Microsoft.Signed
Must never reference both at the same time

bartelink · 2014-09-27T11:10:38Z

@cdrnet No, not suggesting one can always be expressed in terms of the other.

Just saying they use a Null Object pattern in some cases.

I agree your example def can not be expressed that way.

The specific thing I was referring to is that in 4.0 there is a DLL whereas in 4.5 its in core FW. They could have extracted a package for 4.0 and put in a conditional dep but they have not yet. (They have quite a few DLLs in there and arguably they should split to avoid having to put so many redundant copies of things). But obviously that leads to stacks of packages. Old DRY vs Rule of 2-3+ thing etc.

cdrnet · 2014-09-27T12:58:17Z

Ah ok, thanks for the clarification.

forki · 2014-11-19T15:23:57Z

the current Paket version generates the following lockfile for your case:

NUGET
  remote: http://nuget.org/api/v2
  specs:
    FAKE (3.9.9)
    FParsec (1.0.1)
    FSharp.Compiler.Service (0.0.67)
    FSharp.Core.Microsoft.Signed (3.1.1.1)
    FSharp.Formatting (2.4.36)
      FSharp.Compiler.Service (0.0.67)
      Microsoft.AspNet.Razor (2.0.30506.0)
      RazorEngine (3.3.0)
    FsUnit (1.3.0.1)
      NUnit (>= 2.6.3)
    MathNet.Numerics (3.2.3)
      TaskParallelLibrary (>= 1.0.2856.0) - net35
    MathNet.Numerics.FSharp (3.2.3)
      MathNet.Numerics (3.2.3)
    Microsoft.AspNet.Razor (2.0.30506.0)
    NuGet.CommandLine (2.8.3)
    NUnit (2.6.3)
    NUnit.Runners (2.6.3)
    RazorEngine (3.3.0)
      Microsoft.AspNet.Razor (>= 2.0.30506.0)
    TaskParallelLibrary (1.0.2856) - net35

So it should only reference TaskParallelLibrary for .NET 3.5. Can you check if it works?

cdrnet · 2014-11-23T19:48:20Z

It seems to work, the resulting project file looks good to me! Thanks!

There is now an issue with a group-specific framework assembly reference, but I'll open a new issue on this.

forki added the bug label Sep 21, 2014

cdrnet added a commit to mathnet/mathnet-symbolics that referenced this issue Sep 21, 2014

Paket: workaround for fsprojects/Paket#140

6186be7

bartelink mentioned this issue Sep 22, 2014

Support (Conditional) Framework Assembly References #146

Closed

cdrnet changed the title ~~Conditional indirect dependencies (TargetFramework) not respected~~ Support group-specific dependencies Sep 27, 2014

ctaggart mentioned this issue Sep 28, 2014

convert-from-nuget failing with Error in resolution #175

Closed

cdrnet mentioned this issue Oct 4, 2014

Bundle RazorEngine.dll which works on mono fsprojects/FSharp.Formatting#203

Closed

ilkerde mentioned this issue Oct 6, 2014

Create a "use exactly this" operator in order to override package conflicts #220

Closed

cdrnet mentioned this issue Oct 19, 2014

Paket is referencing zLib.Portable when you reference FSharp.Data even in full .NET builds #275

Closed

ctaggart mentioned this issue Oct 28, 2014

Fleece should not include LinqBridge for a .NET 4.5 project #307

Closed

cdrnet closed this as completed Nov 23, 2014

forki mentioned this issue Dec 21, 2014

Lock file has incorrect .NET framework lock #462

Closed

forki added a commit that referenced this issue Oct 30, 2015

Create regression test for #140

2390168

forki added a commit that referenced this issue Oct 30, 2015

Create regression test for #140

1a7b9e7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support group-specific dependencies #140

Support group-specific dependencies #140

cdrnet commented Sep 20, 2014

cdrnet commented Sep 20, 2014

cdrnet commented Sep 20, 2014

forki commented Sep 21, 2014

cdrnet commented Sep 21, 2014

forki commented Sep 21, 2014

forki commented Sep 21, 2014

bartelink commented Sep 21, 2014

forki commented Sep 21, 2014

cdrnet commented Sep 21, 2014

forki commented Sep 21, 2014

cdrnet commented Sep 21, 2014

bartelink commented Sep 25, 2014

cdrnet commented Sep 27, 2014

bartelink commented Sep 27, 2014

cdrnet commented Sep 27, 2014

forki commented Nov 19, 2014

cdrnet commented Nov 23, 2014

Support group-specific dependencies #140

Support group-specific dependencies #140

Comments

cdrnet commented Sep 20, 2014

cdrnet commented Sep 20, 2014

cdrnet commented Sep 20, 2014

forki commented Sep 21, 2014

cdrnet commented Sep 21, 2014

forki commented Sep 21, 2014

forki commented Sep 21, 2014

bartelink commented Sep 21, 2014

forki commented Sep 21, 2014

cdrnet commented Sep 21, 2014

forki commented Sep 21, 2014

cdrnet commented Sep 21, 2014

bartelink commented Sep 25, 2014

cdrnet commented Sep 27, 2014

bartelink commented Sep 27, 2014

cdrnet commented Sep 27, 2014

forki commented Nov 19, 2014

cdrnet commented Nov 23, 2014