Support for .NET Standard

[MatthiasPorges]

Is it planned to add .NET Standard support to the ArcGISRuntime (or mainly the Esri.ArcGISRuntime.Geometry part)?

I haven't seen anythiong about it.
I have a lot of shared code between web services and Xamarin apps (we use .NET Standard libraries for that). We plan on using the ArcGISRuntime for mapping on the apps so it would be neat to use the geometry operations on the backend as well.

[dotMorten_esri]

We would require minimum .NET Standard v2.0 and it would force us to introduce a range of breaking changes and significantly increase the system requirements. We'd like to potentially do this in the future, but it's some ways out due to these constraints (We have actually already done infrastructure changes to make it easier to potentially build for .NET Standard in the future).

Until then, you can use shared libraries instead to re-use your code across multiple projects.

Having said that, due to licensing restrictions you cannot use the ArcGIS Runtime on your backend (and you don't really need .NET Standard do that anyway).

Also consider that the .NET Runtime really is just a thin wrapper around a bunch of native C++ code. So just because you get .NET Standard libraries to compile against, if the native library for the specific platform you're running on isn't available (ie Tizen, Linux, MacOS etc) it still wouldn't work, as we're currently only shipping Android, iOS, Win32 and UWP native libraries.

Also see the discussion here:  https://community.esri.com/message/688315-xamarinforms-are-pcl-projects-supported#comment-707268

[MatthiasPorges]

To be honest - just the Esri.ArcGISRuntime.Geometry part would be enough. Is it impossible to separate it from the rest? They aren't really plattform-specific and I would assume pretty stand-alone.
The same set of features is already available for .NET Framework and .NET Core through NuGet packages so I would assume targeting .NET Standard for this part wouldn't be that hard.
I would rather not use shared code projects for this.
The Geometry classes offer very rich geometry operations and datatypes. Just sharing those on client and server would be very handy.

Licensing wouldn't be much of an issue for us. We already have the new licensing servers and would just buy whatever additional Esri product we need.

[dotMorten_esri]

The same limitations pertain to the entire API. Most the API actually is not platform specific - but the underlying implementation is compiled for each platform, and the system requirement increases that I mentioned still apply.

I'm not sure what you mean by .NET Framework/.NET Core already have those features. They don't have ESRI's geometry model inside them..

> Just sharing those on client and server would be very handy. [... ] Licensing wouldn't be much of an issue for us.

And still you _cannot_ use the ArcGIS Runtime on a server. It's very much against the ArcGIS Runtime license agreement. There is no license you can get that allows the use of Runtime on a server.

> I would rather not use shared code projects for this.

Then create a .NET Standard reference assembly with the same class signatures as the geometry types and use bait'n'switch to get around this limitation (this is in the end what we'd be doing too).