Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
.NET Core version #318
Comments
|
@hello Simon, Right now the project is supported on .NET core through the Portable Accord.NET packages, which are currently provided by the CureOS Shim project, but officially supported by both projects. Hope it helps! Best regards, |
zeroskyx
commented
Oct 9, 2016
|
Hi Cesar, thank you very much for your fast response! The following is the respective output from the package manager: PATH=.\node_modules.bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\git I tried the last pre-version (https://www.nuget.org/packages/portable.accord.vision/3.1.0-pre). Best regards |
|
Hi guys, no, I would not expect the portable libraries to work out-of-the-box on .NET Core, some adaptations are required. In particular, libraries with imaging functionality are not applicable in .NET Core. On the other hand, the portable libraries should at least support UWP already today. I hope to get time to fully adapt the portable libraries to .NET Core, but as it is right now I am a little short of time. Regards, |
|
Hi again, I wanted to add that with .NET Core the need for a portable subset of Accord might not even be warranted, at least for the non-imaging libraries. I have made extremely basic tests on AForge.Core, and it is possible to build it practically without changing any code and without referencing the Shim library. For example, there are .NET Core compatible NuGet libraries coming up for binary serialization (currently in pre-release), which will make building considerably easier. I'll keep you updated with my progress on this. Regards, |
|
Hi Anders, Simon, My apologies. I was under the impression that .NET core was quite similar to UWP and the Shim would work for it. I guess I have to catch up a bit with the differences between the latest .NET flavors before making such statements. Anders: I have been thinking for a while now about removing Accord.Imaging's dependence on System.Drawing and creating a separate Accord.Imaging.WinForms (or similar) to keep existing functionality. Do you think this would make things easier for you, or do you think it would be better to do this solely from the Shim side? Regards, |
@cesarsouza I think that would be a splendid idea! If you could make the (core) imaging library platform agnostic, it would be much easier to "plug-in" rendering adapters for various platforms on top of that. I have done similar things in a few other packages, in particular fo-dicom and CSJ2K, so at least theoretically I can help out, although I am a little bit short of time for the moment. |
|
It seems I can base Accord.Imaging on System.Drawing.Primitives and UnmanagedImage instead. Since all filters are written to handle UnmanagedImage at their core, it shouldn't take much effort. Overloads for Bitmap can be offered by the .WinForms binary through extension methods, which should avoid breaking compatibility too much. |
|
I ran a quick .NET Standard 2.0 compatibility test with the ApiPort tool on the 3.3.0 .NET 4.5 Release binaries, and here is the verdict:
Please note that .NET Standard 2.0 is not yet released! I do not know the exact time frame for public availability. .NET Standard 1.x is considerably less compatible overall. Of course, the controls and imaging based libraries are not expected to be highly compatible, since I am enclosing the full report for detailed information of API incompatibilities. UPDATE OCT 17 Please be aware that the compatibility results for the audio projects are misleading. The third party SharpDX libraries which are an essential part have not been considered in the review. |
|
Thanks a lot Anders, this is ultra useful. On a side note, I couldn't use System.Drawing.Primitives as I initially planned. Even after adding the reference through NuGet, it seems the compiler cannot see the types exposed by the library. Even when trying to inspect it in the object browser I cannot see any types. Do you perhaps know if there is anything extra that has to be done in order to reference a .NET standard/core library in a full .NET 4.6 project? Regarding incompatibility with ADO, we could just remove methods that rely on them with some preprocessor directives. Their presence should not be critical to any of the assemblies in project. |
I haven't too much experience with it myself yet, but from what I know referencing a .NET Standard library in a .NET 4.5 and higher project is fairly straightforward, pretty much like referencing a PCL project. .NET Standard 2.0 will be applicable to .NET Framework 4.6.1 and higher, see here. |
cmaart
commented
Feb 16, 2017
|
+1 |
dbruning
commented
Apr 18, 2017
•
|
From the .NET Core roadmap: I'd love to be able to use Accord.NET from a UWP project. I tried the portable.accord library but got stuck on a variant of this issue. I'm going to wait until UWP and Accord.NET are both on .NET Standard 2.0, in the hope that by removing some of the hoops that portable.accord is jumping through, that native compilation issue goes away too. |
sophisma
commented
Apr 21, 2017
•
|
Hi guys, I'm trying Xamarin Forms and Accord for the first time so, I'm sorry if this is very basic. Package portable.accord.machinelearning 3.0.2.60302 is not compatible with netstandard1.4 (.NETStandard,Version=v1.4). Package portable.accord.machinelearning 3.0.2.60302 supports: portable-net45+win8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile111)
Is there anything that can be done to install this on a NetStandard Project? |
vpenades
commented
May 10, 2017
|
Regarding Net.Standard compatible imaging libraries (for interoperability), there's two very promising libraries... both compatible with Net.Standard 1.3: ImageSharp is a pure image processing library, it's in it's early development stages but worth following. SkiaSharp is the actual rendering engine of Google Chrome, freed as open source and made fully cross platform, adopted by xamarin to be the backend rendering system for xamarin.forms. Both provide very complete Bitmap processing features. |
|
An even simpler approach is to use the CoreCompat System.Drawing package for .NET Standard 1.3 and higher, which is fully compatible with the System.Drawing namespace. Using this package, Accord.NET image processing code would be applicable without modification on .NET Core. |
|
UPDATED MAY 15 Since .NET Core and Standard 2.0 Preview 1 was released last week, I'd thought I should check the compatibility of some of the Accord class libraries. Here are my results so far, using preprocessor directive NET46 where relevant:
So in summary, libraries that do not include explicit Windows Forms and/or sound functionality can be built practically without modification for .NET Standard 2.0. System.Drawing based packages rely on the System.Drawing for .NET Core NuGet package that targets .NET Standard 2.0. It should be noted that the device specific video libraries rely on P/Invoke calls and might therefore only be functional on Windows. For those feeling inclined to test .NET Standard 2.0 compatibility themselves, the adopted project files are available in respective project folder in my personal fork of Accord.NET Framework. |
|
Amazing! Thanks Anders! I've started creating a new solution file for the project to target .NET Standard 2.0. Regards, |
cesarsouza
added a commit
that referenced
this issue
Jun 1, 2017
|
|
cesarsouza |
4780e21
|
|
Hi everyone, I have just committed a new solution file (named As such, I guess the next step would be to resolve Issue #407, porting the existing unit tests to the newer fluent syntax used in NUnit 3. I will probably start this task by tomorrow. Regards, |
|
@cesarsouza In my ".NET Standard sandbox fork" I made some attempts with unit tests as well. The issues I could identify so far (Core, Math, Statistics, Machine Learning and IO tested) when moving to NUnit 3 are these:
There is replacement source code for I have not figured out a sufficient replacement for |
cesarsouza
added a commit
that referenced
this issue
Jun 3, 2017
|
|
cesarsouza |
e738aeb
|
|
Thanks @anders9ustafsson! Actually I thought this was going to be much harder. I thought it was mandatory to convert all Assert's and others to their fluent versions (i.e Assert.That, etc). I've just committed a version of the unit test projects that currently compile under .NET Standard 2.0. However, I wasn't able to actually run them yet. It seems there is no NUnit Test Runner for VS2017 / .NETStandard yet (nunit/nunit3-vs-adapter#305). I've tried to implement some of the workarounds listed in that issue page (installing NUnit Test Runner 3.8.0-preview, adding full debug to the test assemblies), but I couldn't make much progress. I will try again tomorrow. Regards, |
|
@cesarsouza It was not entirely straightforward, but what I did was to create a console application and add a specific test runner to each unit test library. I don't remember right now where I got the code from, but you can look at the test runner here. It relies on NUnitLite, so if you have not added that package already, you will need to (in parallel with NUnit). It's not a very flexible solution, I am afraid. I have not found any way to run only a sub-set of the tests yet, for example. |
|
@cesarsouza BTW, have you been able to work your way around the |
|
For the moment I am not including ExcelReader in the .NET Standard release, but I can add it back later. Thanks a lot for the ExcelDataReader suggestion @anders9ustafsson By the way, I have just uploaded some pre-release (alpha) netstandard packages to NuGet. I haven't tested any of them yet, though. |
cesarsouza
referenced
this issue
Jun 10, 2017
Open
VerificationException: Operation could destabilize the runtime #134
cesarsouza
added the
pending-release
label
Jun 23, 2017
|
Added in release 3.6.0. |
cesarsouza
closed this
Jul 7, 2017
vpenades
commented
Jul 7, 2017
|
Great!, it's nice to see things are moving in the right direction! Now it's a matter of waiting for Net.Core, Xamarin and UWP to catch up with net.standard 2.0, which I guess will happen by the end of the year. |
zeroskyx commentedOct 7, 2016
Greetings,
are there any plans to provide a .NET Core version (netstandard) for this framework in the near future?
This would allow new applications such as running on very different platforms.
Thanks in advance and best regards
-Simon