.NET Standard support for new VS2017 project format

[ryanblackwell]

Created independent solution and project files demonstrating .NET Standard support and targeting multiple frameworks in the new project format. Have not attempted to support additional targets such as .NET 35 and Portable.

[lennoncork]

@cdrnet Is there anything else you would like incorporated into this pull request? Ryan and I are on the same team and we can work together to make some progress while we're motivated.

[ivandrofly]

aren't these only required for .net35?

<ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="System.Numerics" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Runtime.Serialization" />
    <Reference Include="System.Xml" />
</ItemGroup>

So you may want to add some condition <>

<ItemGroup Condition=" '$(TargetFramework)' == 'net35' ">
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="System.Numerics" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Runtime.Serialization" />
    <Reference Include="System.Xml" />
</ItemGroup>

[ryanblackwell]

I believe you are correct. I've made the changes and everything's still working fine. Will wait for any additional feedback from Christoph before pushing.

[aignas]

Just wanted to leave a word that I can load this successfully on ArchLinux with the JetBrains Rider IDE. Thanks!

I also tried to build it using:

dotnet restore Math.Numerics.2017.sln
dotnet build Math.Numerics.2017.sln -f netstandard1.6

The projects build did not work, but it is highly likely to be a setup issue. I can help debugging this if someone is interested, but I do not think that this PR should be affected in any way due to my "build on Linux" issue.

[saan800]

Hi
Is there an ETA on when this will get merged and put up into nuget?
I'd really like to use this library in a netstandard project i'm building

Thanks

[sebandraos]

@lennoncork @ryanblackwell Just out of curiosity, is there any reason you are aiming as high as 1.6? It has always been my assumption that one should target as low as possible with .NETStandard and given that until the 2.0 tooling is RTM 1.6 is only compatible with .NET4.7+ (and at which point it might make sense to jump straight to .NETStandard2.0 as has been suggested by Christoph) it would seem to make sense to reduce the level as much as possible. 1.0/1.1 might be unreasonable but 1.4 could be a good compromise given that it's the current level which will be compatible with the same .NET Framework as 2.0. I'm obviously not taking into account the potentially numerous frameworks pre 4.5 which aren't compatible with any .NETStandard but hopefully that's by the by.

[eriove]

Since portable libraries (that exists today) is more or less the same as .NETStandard 1.0 that should be the easiest to target. My guess is that it is the native providers that will create problems but just like they are missing from the portable libraries (if I understand things correctly) those could be left for later releases. Multi-targeting different versions of .NETStandard is quite easy once the first is set up.

[aignas]

Just out of interest, I have rebased @ryanblackwell's changes on the latest master and added the following:

• Numerics now supports netstandard1.3 (System.Runtime.Serialization.Formatters requires at least netstandard1.3)
• TestData now support netstandard1.1
• netstandard has proper cryptographic PRNG support
• netstandard compilations define NETSTANDARD flag, which does not depend on a specific netstandard version.
• Removed reference includes for netstandard builds because they only cause warnings and nothing else.

Feel free to cherry pick any changes from https://github.com/aignas/mathnet-numerics/tree/feature/vs2017.

If there is desire for me to create a separate PR and do the final tidy up before the merge, let me know. :)

[aignas]

I have also completed the unit-test porting to necoreapp1.1/2.0.

I was using NodaTime as a model on how to have the tests suitable for running with multiple frameworks.
Link: https://github.com/nodatime/nodatime/tree/master/src/NodaTime.Test

In order to run the tests (works under Linux):

dotnet run -f netcoreapp1.1 -p UnitTests-2017.csproj

The output from the initial run:
https://gist.github.com/aignas/cae21fa4b0b5258020c7960d489e5295

Summary:

• 4 Failures
• 9 Errors

[aignas]

And I got all of the tests passing on my local branch. Some notes about what I have discovered about netstandard.

In case you would like to run a single test instead of all the unit tests, use the following shell command(nunit docs):

$ dotnet run -f netcoreapp1.1 -p Test.csproj --where "method == METHODNAME"

I had the following classes of failing tests:

• Matrix<Complex64>: Serialization tests.
• RandomNumberSource: DataContract tests.
• Complex32: TextHandling tests.

Matrix Complex64 failure

It seems that this failure is because the serialization support for Complex in System.Runtime.Numerics got cleaned up a while ago. It is reintroduced in netstandard2.1 and this PR is already merged.
One solution to this would be to back-port the changes in the compatibility layer and once 2.1 is released, add that as a targeted platform as well and for 2.1 upwards use the upstream version of Complex.cs.

I chose to define NOSYSNUMERICS flag for the netstandard target. If this is not satisfactory, let me know.

Serialization of the RandomSources

It seems that the tests fail because the [DataContract] cannot be applied to System.Random class because they removed quite a lot of serialization stuff at some point and they added it later and then removed it again. IMHO, the best approach would be to deprecate serialization for these types altogether because in the last PR the dotnet people say that these types are not meant to be serializable anyway and this is the position of dotnet developers.

The locale test failures

These were failing because of missing string comparison APIs compared to .NET framework. I am not too familiar with that side of things, so I disabled the running of the tests.

[lennoncork]

@sebandraos, @eriove and @aignas this was our first real attempt to netstandard something as it was one of the baseline dependencies. We haven't done any work since and @ryanblackwell has returned to his studies so we weren't planning on any additional work just yet. However we're very keen to see this go in, so let me know what you need and I'll see if I can find someone on the team to make it happen.

[aignas]

@lennoncork, I think that the branch in which I developed is complete (or should be almost there) so if there is any desire from the maintainers to get this into master, I could open a different PR and we could review the changes I made and hopefully get it merged.

[petriashev]

Any progress?
Absence of .netstandard in Math.Net is the only stop factor for our Linux deployment.

[cdrnet]

Closing this, since this has been covered by another PR in the meantime and the first alpha releases of v4 with .Net Standard 1.3/2.0 support are out. Please let me know if you have any issues. Thanks a lot for your contributions!