Open TheAngryByrd opened 7 years ago
why do you need the different versions of FSharp.Core for netcore and full-framework? The package has all the different versions of FSharp.Core for those runtimes. Example:
$ tree . [16:45:30]
.
āāā net20
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā net40
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā net45
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā netstandard1.6
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā portable-net45%2Bmonoandroid10%2Bmonotouch10%2Bxamarinios10
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā portable-net45%2Bnetcore45
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā portable-net45%2Bnetcore45%2Bwp8
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā portable-net45%2Bnetcore45%2Bwpa81%2Bwp8
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā portable-net45%2Bsl5%2Bnetcore45
āĀ Ā āāā FSharp.Core.dll
āĀ Ā āāā FSharp.Core.optdata
āĀ Ā āāā FSharp.Core.sigdata
āĀ Ā āāā FSharp.Core.xml
āāā xamarinmac20
āāā FSharp.Core.dll
āāā FSharp.Core.optdata
āāā FSharp.Core.sigdata
āāā FSharp.Core.xml
you can see the net45 and netstandard1.6 versions of FSharp.Core are there already, all in the same package (FSharp.Core 4.1.17 in this case)
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 Doing something like this is messy one way or another.
pack
currently handles that)
-> On the other side you actually test that everything works for users of your nuget package.from https://github.com/fsprojects/Paket/issues/2612#issue-250138259 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.
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.
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 could you comment on this? Is this something which should be documented here?
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?
Description
I'm trying to move this type of code to from nuget to paket
However when I move to setup below I get this error and similar (truncated since it's very long)
Repro steps
paket.dependencies
paket.references
fsproj
Then run
dotnet restore
onsrc\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
Known workarounds
Use nuget š
Version info