Porting to .Net Core

[gabrielkotev]

Hi, I have one question about using the project in .Net core. Is it possible to port the project to .Net core? or are there too many .Net 4.5 dependencies ?

[MysteryDash]

I'd like to add that naming this repository "encog-dotnet-core" mislead the user into thinking that it has been made for .NET Core.

[jeffheaton]

The name encog-dotnet-core refers to it is the "core" Encog project. Just like there is the encog-java-core project. It predates the .Net core project.

Does .Net core code work on regular .Net or is this a whole new platform to support?

[MysteryDash]

.NET Core and .NET Framework are a bit different, they don't share all of the existing APIs. However, .NET Core and .NET Framework both share .NET Standard (Microsoft recently deprecated the PCL for .NET Standard 2.0, so today if you want to make a library .NET Standard 2.0 is the way to go).

Here's a little diagram Microsoft made : You will probably learn more by reading about the new stuff on Microsoft's blog.

I ran the Portability Analyzer on Encog and around 86% of the assembly is compatible with .NET Standard 2.0. Here are the actual results : Api Port Analysis.xlsx.
You can see that the main stuff preventing a conversion to .NET Standard comes from System.Windows.Forms. I believe this may not be necessary to encog as user interaction should not be part of this library. As for System.Drawing.Image and System.Drawing.Bitmap, it has yet to be implemented in the .NET Standard, as the current implementation in .NET Framework relies on non-portable GDI+ code (see this issue). However, I have used ZKWeb.System.Drawing (on System.DrawingCore) as a temporary solution to port one of my projects with no noticeable difference (the actual System.Drawing shouldn't take much longer before being released). Plus it might as well give opportunities to improve performance where there is room for it (I noticed some Image.GetPixel here and there, which is very slow compared to LockBits, but it should probably have its own issue).
Encog-java-core has the benefit of being cross-platform. Encog-dotnet-core can be cross-platform too without having to rely on non-standard solutions like Mono, so I like to believe that it might be possible to port encog to .NET Standard.

[MysteryDash]

So, I locally tried to make a basic port of Encog to .NET Standard 2.0, and the results are pretty good.

• Because there is no real way around it (.NET Standard does not include any User Interface API whatsoever), I had to strip away everything that dealt with a Form (and to be honest I still don't see in what way these are important to the Encog Framework). As a matter of fact I literally obliterated most of the stuff in Encog.ML.Data.Market (but well, considering ichart.finance.yahoo.com is gone it wasn't a great loss).
• As it is not planned by the .NET Core team to implement the OleDb in .NET Standard or .NET Core, I had to strip that too, meaning no SQL in Encog anymore. However, this can easily be replaced in a real port. OleDb is not the sole Sql provider that exists for .NET.
• I also had to quickfix a few mistakes from the lasts commits since Encog doesn't compile really well currently, but that is an unrelated matter.
• Finally I removed that weird Stopwatch class (it did not compile correctly, and anyway there is a better implementation in System.Diagnostics, no need to reinvent the wheel).

I have yet to test the result of this "port" but considering I did not change the original code it should still work correctly (except for all these Forms). So porting Encog to .NET Standard (to the current latest version 2.0) is definitely doable,

[jeffheaton]

Thanks for all of the info. I probably have some reading to do. The parts of Encog that use forms are mostly contributed classes that are not at all central to what Encog does. I could move those to another DLL file. I am not too fond of the idea of splitting Encog into 3 .Net flavors, it takes enough time just keeping Encog Java and C# synced up. But I will read up more on how might be the best way to support the various .Net variants.

[MysteryDash]

I am not too fond of the idea of splitting Encog into 3 .Net flavors

You might have misunderstood me here, supporting .NET Standard means supporting .NET Framework and .NET Core at the same time.
I perfectly understand that it is hard to maintain both the Java and C# versions of Encog, you're already doing an awesome job.

[IntegerMan]

I feel like this repository should probably be renamed. I read the name and assumed that it referred to a .NET Core (or .NET Standard) implementation of Encog, not the core implementation of Encog in .NET. It wasn't until I added a NuGet reference and observed an issue on the dependency that I discovered the error of my assumption.

[jeffheaton]

The reason it is named "core" is because the library in Java, C#, C, and JavaScript that contain the core functions is named "core". I don't want to rename C# version (which would have some breaking changes) and leave the others as as. They were all named in 2008, well before the .Net side fragmented into several different run times.

I do not currently have time to port this to the various .Net CLR forks, I would be glad to merge such changes.

[IntegerMan]

Can you even do a pull request to rename a repository? That's usually governed in repo settings.