Add a .Net "standard" version. about gjallarhorn HOT 16 CLOSED

Published and released in 1.2.0 - https://www.nuget.org/packages/Gjallarhorn/1.2.0

from gjallarhorn.

Apparently VS supports .NetStandard 2.0 projects now. It'd be great if this could be updated to remove the warnings when installing :)

from gjallarhorn.

@charlesroddie was planning to do one - just haven't had the time to update it all yet. Would be happy to accept a PR at this point if anybody wants to tackle it, though. This is partly due to the fact that VS has only just started supporting it properly.

Now that it's supported in VS, I don't mind making it purely NS 2.0 .

from gjallarhorn.

@ReedCopsey - I've just done a spike (purely for learning) on taking this to net core, so I'd be happy to take this on under guidance - e.g. net core 2.0 or net standard 2.0?, on a new branch? etc.

from gjallarhorn.

I plan to migrate completely to NetStandard 2.0 once it works seamlessly for F# projects in VS. Given that most of my users are currently doing WPF work, supporting WPF and trying to build as NS2.0 would mean splitting into lots of repositories, which makes life very difficult for me and most users.

from gjallarhorn.

I was just interested in trying this out with Xamarin.iOS/Droid and having a .Net standard version would be ideal. Not sure why you need a 2.0 version?

from gjallarhorn.

@7sharp9 The library is PCL 259, which should work. Is there a reason you can't just use it today?

I can't move the main xamarin project over to netstandard without 2.0 support because it uses some of the reflection API that's not exposed in <NS2.0. Given the state of tooling today, I don't really want to move them over in pieces, as it will significantly complicate the build workflow and usability for development.

from gjallarhorn.

@alfonsogarciacaro how about doing a .net standard fork of this if @ReedCopsey doesn't already have one?

Then we can link to it in our build... which is basically what we are having to do already albeit ham-fistedly.

from gjallarhorn.

@mtnrbq All of the PCL projects, in theory, should be able to migrate to net standard 2.0 instead of PCL, with the other projects upgraded to the latest .net framework referencing them. Gjallarhorn.BIndable would also need to be migrated (again, all PCL + Xamarin projects) in a similar manner.

from gjallarhorn.

@ReedCopsey - making some good progress, except hitting issues with unit-test project support. would be good to have a more detailed discussion - is this (GitHub issue comments) the best place ?

from gjallarhorn.

@mtnrbq I'm happy to do it here, but also the FSSF slack would be a good option... I'm on there most days, so feel free to ping me anytime.

from gjallarhorn.

Some problems with current master. Using Visual Studio 2017 15.5.

Add a new project - Console App (.NET Core) (Visual F#) - in the Gjallarhorn solution. Reference The Gjallarhorn project. Build. Run. Error message:
"Could not load file or assembly 'FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

Add a Console Application (Visual F#) in the Gjallarhorn solution. Reference the Gjallarhorn project. Error message: "A reference to library 'Gjallarhorn' cannot be added. This project targets a different framework (.NETStandard) from the current project (.NETFramework).

The first type of problem is a long-running problem with Gjallarhorn, but I am posting here as neither problem exists when referencing the latest nuget package 1.1.0 from either type of project. So this may have to do with the lastest changes.

from gjallarhorn.

@charlesroddie - I've temporarily published a pre-release nuget version of Gjallarhorn as https://www.nuget.org/packages/Gjallarhorn_mtnrbq/ - using this I have not had the issues you mention, but you could retry referencing this.

from gjallarhorn.

I still get this issue on run from a .NET Core 2.0 project: Could not load file or assembly 'FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

On build there are these warnings:
...GjallarhornTestApp.fsproj : warning NU1605: Detected package downgrade: FSharp.Core from 4.3.3 to 4.2.3. Reference the package directly from the project to select a different version.
...GjallarhornTestApp.fsproj : warning NU1605: GjallarhornTestApp -> Gjallarhorn_mtnrbq 2.0.0-alpha -> FSharp.Core (>= 4.3.3)
... GjallarhornTestApp.fsproj : warning NU1605: GjallarhornTestApp -> FSharp.Core (>= 4.2.0)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2041,5): warning MSB3277: Found conflicts between different versions of "FSharp.Core" that could not be resolved.

This is from Visual Studio 2017 15.5.6. The FSharp.Core nuget packages do seem to be broken at the moment so that could be the issue.

from gjallarhorn.

@charlesroddie it's not a problem of Gjallarhorn. NuGet notice some conflict with versions of FSharp.Core. One is "default" and one from dependencies of Gjallarhorn.

Workaround (if you don't have another package with dependencies with FSharp.Core) - change .fsproj and specify:

 <FSharpCoreImplicitPackageVersion>4.3.4</FSharpCoreImplicitPackageVersion>

I guess you won't have such problem with paket.

from gjallarhorn.

OK thanks for info and sorry for false alarm then. Hopefully the F# nuget package will stabilize soon.

from gjallarhorn.