Group conditions for dotnet sdk projects

Description

I'm trying to move this type of code to from nuget to paket

  <ItemGroup Condition="'$(TargetFramework)'=='net45'">
    <PackageReference Include="FSharp.Core" Version="4.0.0.*" />
  </ItemGroup>
  <ItemGroup Condition="'$(TargetFramework)'=='netstandard1.6'">
    <PackageReference Include="FSharp.Core" Version="4.1.*" />
  </ItemGroup>

However when I move to setup below I get this error and similar (truncated since it's very long)

/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error : Package System.Globalization.Calendars 4.3.0 is not compatible with net45 (.NETFramework,Version=v4.5). Package System.Globalization.Calendars 4.3.0 supports: [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - monoandroid10 (MonoAndroid,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - monotouch10 (MonoTouch,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - net46 (.NETFramework,Version=v4.6) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - netstandard1.3 (.NETStandard,Version=v1.3) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - xamarinios10 (Xamarin.iOS,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - xamarinmac20 (Xamarin.Mac,Version=v2.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - xamarintvos10 (Xamarin.TVOS,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - xamarinwatchos10 (Xamarin.WatchOS,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]

Repro steps

paket.dependencies

group full
    condition: FULL
    framework: net45
    source https://www.nuget.org/api/v2
    nuget FSharp.Core 4.0.0.1
group core
    condition: CORE
    framework: netstandard1.6
    source https://www.nuget.org/api/v2
    nuget FSharp.Core 4.1.17

paket.references

group core
FSharp.Core
group full
FSharp.Core

fsproj

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.6;net45</TargetFrameworks>
  </PropertyGroup>
  <PropertyGroup Condition="'$(TargetFramework)'=='net45'">
     <FULL>true</FULL>
  </PropertyGroup>
  <PropertyGroup Condition="'$(TargetFramework)'=='netstandard1.6'">
    <CORE>true</CORE>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Library.fs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
  </ItemGroup>
  <Import Project="..\..\.paket\Paket.Restore.targets" />
</Project>

Then run dotnet restore on src\MyLib

https://github.com/TheAngryByrd/paketConditonNetcore

Expected behavior

Ability to restore and build net45 and netstandard1.6 with different versions of FSharp.Core

Actual behavior

/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error : Package System.Globalization.Calendars 4.3.0 is not compatible with net45 (.NETFramework,Version=v4.5). Package System.Globalization.Calendars 4.3.0 supports: [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - monoandroid10 (MonoAndroid,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - monotouch10 (MonoTouch,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - net46 (.NETFramework,Version=v4.6) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - netstandard1.3 (.NETStandard,Version=v1.3) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - xamarinios10 (Xamarin.iOS,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - xamarinmac20 (Xamarin.Mac,Version=v2.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - xamarintvos10 (Xamarin.TVOS,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]
/usr/local/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error :   - xamarinwatchos10 (Xamarin.WatchOS,Version=v1.0) [/Users/jimmybyrd/Documents/GitHub/classLibTemplate/Content/src/MyLib/MyLib.fsproj]

Known workarounds

Use nuget 😭

Version info

Mono JIT compiler version 4.8.1 (mono-4.8.0-branch/22a39d7

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.11
 OS Platform: Darwin
 RID:         osx.10.11-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1

Paket version 5.0.0-beta010

Well I guess I want to end up with this as my dependency tree on nuget when I go to pack it

Dependencies
.NETFramework 4.5
FSharp.Core (>= 4.0.0.1)
.NETStandard 1.6
FSharp.Core (>= 4.1.2)
NETStandard.Library (>= 1.6.1)

If someone is consuming my lib on net45, i don't want to force them to update their FSharp.Core dependency

@baronfel

@baronfel Doing something like this is messy one way or another.

You can cheat and just edit the deps of the resulting package
-> You don't actually know if you are still compatible with the older package.
You use conditions and multiple groups
-> You need to do a lot on your own (I'm not even sure how pack currently handles that)
-> On the other side you actually test that everything works for users of your nuget package.

@yevhen

from #2612 (comment) by @yevhen

In a mixed solution where some of the projects use new VS17 csproj format and target multiple frameworks (net462/nestandard) conditional references are required for some scenarios, such as referencing System.AppDomain for netstandard but not when building for net46.

Example:

<ItemGroup>
  <PackageReference Include="System.AppDomain" Version="2.0.11"
                    Condition="'$(TargetFrameworkIdentifier)' == '.NETStandard'" />
</ItemGroup>

As .net 5 is the way forward, I'm gonna close this.

@TheAngryByrd

As .net 5 is the way forward, I'm gonna close this.

@TheAngryByrd Does it mean that it is not going to be possible until .NET 5 is released? How would .NET 5 help with this?

Everything is going to be .NET 5. There won't really be a .NET core or .NET framework.

Everything is going to be .NET 5. There won't really be a .NET core or .NET framework.

.NET framework will be supported by Microsoft so long Windows variants (with .NET included) are supported. So this problem will still be unsolvable with paket if you need to support both .NET 4 and .NET 5 in your code.

I'm not concerned with supporting super old versions of frameworks. This post covers some similar thoughts I have about supporting older frameworks.

I'm not concerned with supporting super old versions of frameworks.

I hope this doesn't reflect the general consensus here. .NET 5 doesn't replace anything, it's just one more on top. .NET Framework and .NET Core are not going away ...

I'm not concerned with supporting super old versions of frameworks.

I'm sure you don't, but paket as a project did not declare that it's abandoning all versions except .NET 5, so this issue in paket still stands and therefore it should not be closed?

we will continue to support old frameworks as good as we as a community can.

@forki

we will continue to support old frameworks as good as we as a community can.

@forki So shouldn't this issue be reopened then?

I ran into this issue since some libraries only target net5.0 or netcoreapp3.1.

It took me a while to figure this out as it doesn't seem to be documented, but I was eventually able to get conditions working so that it would reference the proper package based on the targeted framework.

paket.dependencies:

group Net5
    source https://nuget.org/api/v2
    source https://api.nuget.org/v3/index.json
    
    condition: net5_0
    framework: net5
    
    ...
    nuget Microsoft.AspNetCore.Authentication.JwtBearer ~> 5


group NetCoreApp3
    source https://nuget.org/api/v2
    source https://api.nuget.org/v3/index.json
    
    condition: netcoreapp3_1
    framework: netcoreapp3.1
    
    ...
    nuget Microsoft.AspNetCore.Authentication.JwtBearer ~> 3

paket.references:

group NetCoreApp3
    ...
    Microsoft.AspNetCore.Authentication.JwtBearer

group Net5
    ...
    Microsoft.AspNetCore.Authentication.JwtBearer

I haven't really dug too deep into the source code, but I suspect that condition needs to be a platform as opposed to something defined in your fsproj.

package.dependencies:

Shouldn't this be paket.dependencies ?

I haven't really dug too deep into the source code, but I suspect that condition needs to be a platform as opposed to something defined in your fsproj.

Looks like preprocessor symbols? But I couldn't even find documentation on condition syntax.

Shouldn't this be paket.dependencies ?

Yes, that was a typo on my part! I fixed it.

Looks like preprocessor symbols? But I couldn't even find documentation on condition syntax.

Yes, it doesn't seem to be documented at all. I figured this out by spending a bunch of time digging through the paket code and ancient issues 😅.

@forki

@forki could you comment on this? Is this something which should be documented here?

@Shmew

Thank you @Shmew for the solution! I've found that order of targets in the project file matters, meaning [1] fails to resolve proper package, but [2] works as expected
[1] <TargetFrameworks>net6.0;netstandard2.0</TargetFrameworks>
[2] <TargetFrameworks>netstandard2.0;net6.0</TargetFrameworks>

Also conditions on dependencies do not work right?

Is someone working on this?

Navigation Menu

Repository navigation

Group conditions for dotnet sdk projects #2394

Description

Repro steps

Expected behavior

Actual behavior

Known workarounds

Version info

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Group conditions for dotnet sdk projects #2394

Description

Description

Repro steps

Expected behavior

Actual behavior

Known workarounds

Version info

Activity

baronfel commented on Jun 5, 2017

TheAngryByrd commented on Jun 5, 2017

matthid commented on Jun 5, 2017

enricosada commented on Jan 24, 2018

TheAngryByrd commented on Mar 26, 2020

older commented on Apr 16, 2020

TheAngryByrd commented on Apr 16, 2020

older commented on Apr 17, 2020

TheAngryByrd commented on Apr 17, 2020

cdrnet commented on Apr 17, 2020

older commented on Apr 20, 2020

forki commented on Apr 23, 2020

older commented on Apr 27, 2020

Shmew commented on Nov 19, 2020

older commented on Nov 23, 2020

Shmew commented on Nov 23, 2020

older commented on Nov 24, 2020

anpin commented on Jun 20, 2023

romerod commented on Oct 10, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions