Net core is a strange step child that no one understands, yet. For a while I thought it was xamarin, or a port of. But the documentation mentions xamarin and core in the same sentence, which apppear to be separate identities.

Having no experience with core, and not many do due to these reasons, I won't be much help.

From the net core website, i found this, which is sadly the most informative bit about core....

The major differences between .NET Core and the .NET Framework:

App-models .NET Core does not support all the .NET Framework app-models, in part because many of them are built on Windows technologies, such as WPF (built on top of DirectX). The console and ASP.NET Core app-models are supported by both .NET Core and .NET Framework. APIs .NET Core contains many of the same, but fewer, APIs as the .NET Framework, and with a different factoring (assembly names are different; type shape differs in key cases). These differences currently typically require changes to port source to .NET Core. .NET Core implements the .NET Standard Library API, which will grow to include more of the .NET Framework BCL APIs over time. Subsystems .NET Core implements a subset of the subsystems in the .NET Framework, with the goal of a simpler implementation and programming model. For example, Code Access Security (CAS) is not supported, while reflection is supported. Platforms The .NET Framework supports Windows and Windows Server while .NET Core also supports macOS and Linux. Open Source .NET Core is open source, while a read-only subset of the .NET Framework is open source.

From: https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcing-net-core-1-0/

Oh, I found the API reference as well. But there's quite a bit missing. For example, the system.drawing doesn't contain managed bitmaps or anything. The ezsdk does use unmanaged bitmaps, but it also uses managed bitmaps for windows integration. With Microsoft removing that functionality in net core, the windows ezsdk will not work.

API reference: https://docs.microsoft.com/en-us/dotnet/core/api/

Drawing namespace: https://docs.microsoft.com/en-us/dotnet/core/api/system.drawing

Due to the lack of support for graphic objects, you'd have to create your own. This is somewhat expected because cross platform of display widgets would be an huge endeavor, specifically for an open source product with no direct revenue stream.

May be easiest to use the windows universal bot (uwp) open source sdk provided by ezrobot and imolementing camera features per operating system if your desire is to compile cross platform.

The ezrobot mobile app is cross platform with xamarin, and there are operating system compliler directives for each android and iOS. This is because the xamarin framework doesn't provide cross platform graphic and audio capabilities.

In short, implementing graphic objects would need to be per operating system and are not included under Microsoft net core API framework, which limits compatibility with libraries such as ezrobot windows sdk

Thanks for your response. It does seem that they are indeed incompatible. I have gotten .net core to install the package from nuget, however when I follow this guide to adding the dependency in package.json.

https://blogs.msdn.microsoft.com/mvpawardprogram/2016/07/19/key-steps-in-developing-net-core-applications/

I get the error:

Unable to resolve 'EZ_B.dll (>= 2015.5.20)' for '.NETCoreApp,Version=v1.1'.

Which seems to imply they keep track of the compatibility somehow inside the nuget system although I can't seem to find where. In anycase I will take a look at the IOT sdk next.

In the mean time the mono sdk does work fine, this whole detour back into the other sdk's was to avoid having to write graphics encoding for the bytecode stream that comes out of EZBv4Video.Start(EZ_B.EZB,System.String,System.Int32), and while I'm thinking about it, do you know what the last arguement (the integer) in the function signifies?

/// <summary>
    /// Connect and begin receiving the camera stream
    /// </summary>
    public void Start(EZB ezb, string ipAddress, int port) {

does visual studio not provide intellisense for you?

this is the "Big Picture" :

source: https://docs.microsoft.com/en-us/dotnet/articles/standard/components

1. EZB.dll (AssemblyFileVersion = 2017.01.05.00) included with ARC requires .NET Framework 4.6.1 and Requires x86/32 bit

2. EZB.dll (AssemblyFileVersion = 2016.05.06.00") included with Windows SDK requires .NET Framework 4.5 and Requires x86/32 bit

3. EZB.dll (AssemblyFileVersion = "2016.05.13.0" included with Mono SDK requires .NET Framework 4.5

All 3 versions are .NET Framework DLLs, theoretically you can have the same DLL working for Windows .NET Framework and Mono .NET Framework, but you need to share the same constrains.

Mono max .NET Framework version 4.5 Mono .NET does not work very well with all code obsfucator tools (used to protect Intellectual Property) Mono .NET does not support some .NET APIs

So is easy to understand Mono .NET is much more limited, needs a different DLL. Since MSFT released .NET Core and open source (some) .NET framework code and bought Xamarin there is no $$$ to fund Mono .NET.

The future is or will be .NET Core, but the pace and the stability is another issue.

Is a huge goal to support a good technology stack (.NET) over a free operating system Linux.

if Linux + .NET Stack is good and free why pay for Microsoft OS ? What will happen to the MSFT OS engineers and I.P. ? Will they go work for free to support Open Source ?

Regarding the UWP is possible to have a single DLL to support UWP applications, or have a limited .NET Core DLL with all the platform specific (graphics, networking and others) addressed outside.

Same thing with Xamarin, you can't use none of the EZB dlls with a Xamarin project, you need to readjust (cut unsupported code) and create a Portable Class dll and only then you can add to the Xamarin Projects.

All the specific parts (graphics, networking, sound, etc) must be handled per project (One Xamarin project for Android, other for IOS etc).

@dj sures i am not using Visual Studio, maybe I will look at VS code, which is the only version that runs on linux to see if I can get that to work to get better documentation than is available in the XML doc that comes with the dll.

@ptp thanks for the info and context.

Will hopefully post something in the coming weeks about how my cross platform ROS / Python / maybe Node integration comes out, that may be useful to other programmers who would find options besides .net for interfacing with the controller useful.

@am3081,

Are you trying to create a ROS Node for EZB ?

If yes is much more simple to use DJ's "Bit Bang" protocol versus going with a Mono .NET dll.

I've created a node for specific project, as you may know there are no ROS standard messages for servos or ports.

The one i have is used for controlling servos and ports and i believe supports analog reads.

Let me know what you need, i can clean up my code, and make it usable.

Yeah, i'm with PTP on assisting you with creating a C++ or C library for ROS that uses the EZ-B protocol, defined here: https://synthiam.com/Tutorials/Lesson/18?courseId=5

It's a very well written document and the protocol commands are easily understood.

@ptp any code you have would be of great interest. I am a little new to programming at the hardware software interface and by example is my favorite way of learning. I I would be super appreciative of anything you would be willing to share.

My longer term goals are to hook up the ez-b to a some deep learning ROS modules I am working on for object recognition and hopefully to then use reinforcement learning techniques to "learn" how to control the servos for some simple motion.

Will be happy to share all my work with the community.

@am3081

Do you have an EZR Camera ?

I do have an EZR Camera.