No netstandard version of ExtCore exists

[jindraivanek]

I have working netstandard1.6 fsproj here: https://github.com/jindraivanek/ExtCore/blob/netcore/ExtCore.netcore/ExtCore.netcore.fsproj

[7sharp9]

For now I just pulled in a few files that I needed via paket, maybe a fork with the net standard project in would allow paket to build this entirely though?

[jindraivanek]

Yes, I'm doing it with github jindraivanek/ExtCore:netcore in paket.dependencies and <ProjectReference Include="..\paket-files\jindraivanek\ExtCore\ExtCore.netcore\ExtCore.netcore.fsproj" /> in fsproj

[jack-pappas]

The latest ExtCore nuget package includes versions targeting various PCL profiles. Besides a netstandard1.6 target, couldn't we just copy the PCL into the appropriate folders in the nuget package? E.g. for netstandard1.0, netstandard1.1, and netstandard1.2?

According to this page, you may already be able to consume the PCL profile-based assemblies from the most-recent ExtCore package if you also reference the Microsoft.NETCore.Portable.Compatibility package (see the section PCL Compatibility): https://docs.microsoft.com/en-us/dotnet/standard/net-standard

[jack-pappas]

Also, you can't build a 'complete' ExtCore without using fsc-proto, regardless of which framework you target. A small number of useful intrinsic functions rely on the inline IL capability available in the proto-compiler, and can't be compiled with the normal F# compiler. Also, some optimized collection types like TagMap rely heavily on the inline IL functionality to perform type-erasure (on the tag / measure type) so the compiled code uses IntMap or LongMap without having to ship basically-identical types and modules for the tagged collections.

[7sharp9]

I wouldn't like to guarantee it will work, stuff like System.Diagnostics.Trace would be in a different assembly than desktop for instance.

[jack-pappas]

I think I figured out how to properly build ExtCore for netstandard TFMs. I'll try to get a new package built and released in the next few days.

Is it worth keeping the PCL-based assemblies in the package (i.e. should I just add these new assemblies), or should the netstandard packages replace them immediately? Seems like they're worth keeping around, at least in the short-term, but if anyone has a good argument for dropping them immediately I'll consider it.

[7sharp9]

Any news on a potential release, I don't think theres harm in keeping the pcl's around for another release, other project do seem to be dropping them now though.

[jack-pappas]

I think I've figured out what I need to do to build this. I haven't had time this past ~week, but will find some time this week (or coming weekend) to build + release.

[jack-pappas]

@vasily-kirichenko did some great work to move the whole project over to netstandard2.0 and I've merged his changes. I'll make a few more tweaks on top of that to do a multi-targeted build -- I still want to have a net461 (or net45) build, and I think we'll want one for netstandard1.6 as well.

[vasily-kirichenko]

It already targets both netstandard 2 and .net 4.5. About netstandard 1.6, I tried and failed - there are some APIs used that do not exists in 1.6

[wallymathieu]

So the version that's in source now, should be nice to have on nuget 😄

[7sharp9]

Having a nuget that targets netstandard2.0 would be great, not having all those netstandard 1.6 dependencies etc.

[7sharp9]

@vasily-kirichenko Can you remember what doesn't work in 1.6?

[wallymathieu]

Look at FX_ATLEAST_PORTABLE in the code ...

[wallymathieu]

Shouldn't be an issue if you use netstandard2.0, since then you should get the full thing.

[vasily-kirichenko]

@7sharp9 no.

[theimowski]

Is there any update to this?

[7sharp9]

not as yet, @jack-pappas recently raised an issue list that would lead to a v1 release

[7sharp9]

RE: #47