The history and future of the ArcGIS SDKs for .NET

[MichaelBranscomb]

http://blogs.esri.com/esri/arcgis/2013/07/05/the-history-and-future-of-the-arcgis-sdks-for-net/

[MichaelBranscomb]

Hi,

The next release of the ArcGIS Runtime SDK for WPF will be 10.2.1 towards the end of the year. At the same time we'll be releasing the new ArcGIS Runtime SDK for .NET which includes the API for Windows Desktop - i.e. a new WPF API. And there will be future releases of the existing WPF SDK, which will include bug fixes and enhancements to synchronize with the rest of the ArcGIS platform (i.e. Server / Online). This means you have time to migrate.

Typically what we've found so far is that migration is quite straightforward, because although it's a new API, it's really an evolution of the existing API - here's the approx process:
#. Open up the project
#. Remove the reference(s) to ESRI.ArcGIS.Client.*.dll
#. Add a reference to Esri.ArcGISRuntime.dll
#. Change the XAML and code namespace statements (i.e. the xmlns and usings)
#. Rebuild... and work through the build errors.
#. The majority of classes and class members share the same names and behave the same way so in many cases your code will recompile after a few modifications and will continue to work as it did with WPF.

However, there are a few changes - the new API...
- is built on .NET 4.5 - so your app. needs to be targeting .NET 4.5.
- makes extensive use of the Task-based async pattern instead of events - so there will likely be some changes to some areas of logic in your app (e.g. Layer.Initialized events, Mouse events).
- will only use the ArcGIS runtime map engine (previously called the accelerated display mode in WPF) which means no support for XAML custom symbols. We are working on equivalency in other areas where the WPF accelerated display mode was lacking, such as rotation.

To help you migrate:
- For the 10.2.1 release of the WPF SDK we've added Task-based async support in many areas to help you start taking advantage of .NET 4.5 features such as the await keyword - but realistically you
- In the 10.1.1 release, you can make sure you're working with the accelerated display mode (and let us know if you experience any issues).
- Join the beta testing in the late summer to test out the new .NET SDK and help us make sure it does what you need it to.

Cheers

Mike

[GeorgeFaraj]

Hey Mike,

Thanks for that detailed response. I am glad that we're getting an improved version of the WPF SDK so that we get that as we ease the transition to the new SDK.

One of the biggest drawbacks of the current SDK is its lack of a proper labeling engine. Are we getting that any time soon?

[HuyHo]

Hi,

The next release of the ArcGIS Runtime SDK for WPF will be 10.2.1 towards the end of the year. At the same time we'll be releasing the new ArcGIS Runtime SDK for .NET which includes the API for Windows Desktop - i.e. a new WPF API. And there will be future releases of the existing WPF SDK, which will include bug fixes and enhancements to synchronize with the rest of the ArcGIS platform (i.e. Server / Online). This means you have time to migrate.

Typically what we've found so far is that migration is quite straightforward, because although it's a new API, it's really an evolution of the existing API - here's the approx process:
#. Open up the project
#. Remove the reference(s) to ESRI.ArcGIS.Client.*.dll
#. Add a reference to Esri.ArcGISRuntime.dll
#. Change the XAML and code namespace statements (i.e. the xmlns and usings)
#. Rebuild... and work through the build errors.
#. The majority of classes and class members share the same names and behave the same way so in many cases your code will recompile after a few modifications and will continue to work as it did with WPF.

However, there are a few changes - the new API...
- is built on .NET 4.5 - so your app. needs to be targeting .NET 4.5.
- makes extensive use of the Task-based async pattern instead of events - so there will likely be some changes to some areas of logic in your app (e.g. Layer.Initialized events, Mouse events).
- will only use the ArcGIS runtime map engine (previously called the accelerated display mode in WPF) which means no support for XAML custom symbols. We are working on equivalency in other areas where the WPF accelerated display mode was lacking, such as rotation.

To help you migrate:
- For the 10.2.1 release of the WPF SDK we've added Task-based async support in many areas to help you start taking advantage of .NET 4.5 features such as the await keyword - but realistically you
- In the 10.1.1 release, you can make sure you're working with the accelerated display mode (and let us know if you experience any issues).
- Join the beta testing in the late summer to test out the new .NET SDK and help us make sure it does what you need it to.

Cheers

Mike

Thanks for the info Mike.   I have a couple of concerns:
1. .NET 4.5 does not support Windows XP.  Many of our customers still run Windows XP.  We cannot go to our customers to tell them to upgrade the OS just to use our software.  Targeting a framework that excludes an OS that's still widely used is not acceptable.
2. You say that the new .NET SDK will not support custom symbols.  Are you going to provide alternatives?  How are we going to display our custom symbols now?

[MichaelBranscomb]

1. .NET 4.5 does not support Windows XP.  Many of our customers still run Windows XP.  We cannot go to our customers to tell them to upgrade the OS just to use our software.  Targeting a framework that excludes an OS that's still widely used is not acceptable.

We've been discussing this subject extensively over the last year, but continuing to support XP is increasingly presenting us with significant challenges in our development as well as preventing us from taking advantage of new features in .NET 4.5. Therefore we recently announced that for the existing WPF SDK the next release (10.2) will be the last major release to support Windows XP. For the new SDK, it's built for Windows Store and Windows Phone 8 as well as the windows Desktop and therefore needs to be built on .NET 4.5.

2. You say that the new .NET SDK will not support custom symbols.  Are you going to provide alternatives?  How are we going to display our custom symbols now?

We are still investigating ways in which we can provide support for custom symbols in the new .NET SDK. One alternative is to use RenderTargetBitmap to render the WPF elements as images then use the images as PictureMarkerSymbols or PictureFillSymbols, although I appreciate that will not work for any animated symbols with StoryBoards, etc. I'd be really interested to see any custom symbols you've defined in XAML - if you're able to share them, you can email me at mbranscomb@esri.com.

Cheers

Mike

[BrianRassier]

I have a couple questions on this topic:

1) Will the new Runtime SDK for .NET have any concept of package-based offline functionality like the current RuntimeLocalServer?
2) The Windows Store SDK lists support for Windows 8 only.  This thread already mentions XP support will not be available.  What about Windows 7 support for the new Runtime SDK for .NET?

[MichaelBranscomb]

Hi,

Thanks for the questions - please note that any details given here may be subject to change...

1) Will the new Runtime SDK for .NET have any concept of package-based offline functionality like the current RuntimeLocalServer?

Yes, we plan to include the new offline geodatabase/routing/geocoding functionality demonstrated in March at the Dev Summit and more recently at the UC within the new Runtime SDK for .NET will include. Additionally, the "Windows Desktop" portion of the new SDK will continue to support existing package-based workflows using the RuntimeLocalServer.

2) The Windows Store SDK lists support for Windows 8 only.  This thread already mentions XP support will not be available.  What about Windows 7 support for the new Runtime SDK for .NET?

Yes, the new ArcGIS Runtime SDK for .NET will support development/deployment of WPF applications on Windows 7 and 8 - that's the "Windows Desktop" API within the new combined SDK. However, the Win Store App and Win Phone 8 portions of the new Runtime SDK will most likely follow Microsoft's system requirements which, as far as I'm aware, are Windows 8 only. For all three APIs it's Visual Studio 2012 and .NET 4.5. We will be investigating support for VS2013.


Cheers

Mike

[Cristian_Galindo]

Hi,

After being involved in an ArcGIS Runtime SDK for WPF training, several concerns came to me:

1. Was a great surprise, discover that it does not allow to perform linear referencing operations (Dynamic segmentations). This kind of operations are available in ArcObjects.

2. You cannot manipulate the map object to add NEW layers connected to a database....or create layers on the fly and add features an then persist it....unless they are tied to a feature service.

3. from my point of view (correct me if i'm wrong) an application developed under this technology is tied up to previously created content, and that content cannot be modified with the freedom that ArcObjects gave tu us (developers), I mean...if i have a map package...i can add, in my application, other layer, but i cannot persist that addition; as well i can load feature packages...and modify the features inside of it, but i am not able of create those packages from my application, and then add them to the map package.

4. maybe i'm searching in the wrong way, but i cannot find the way (in the product reference) to access to a Feature class in a file geodatabase or personal geodatabase

Why to deprecate ArcObjects if they provide such a big opportunity and granularity???

[MichaelBranscomb]

Hi,

You raise some good questions/points... we said from the outset that the Runtime APIs are designed to be lighter-weight, coarser-grained APIs which overcome many of the downsides to ArcObjects (performance, native 64-bit, modular deployment, more flexible licensing, etc).

1. Was a great surprise, discover that it does not allow to perform linear referencing operations (Dynamic segmentations). This kind of operations are available in ArcObjects.

Linear referencing / dynamic segmentation is not on the immediate roadmap, but if it's something you would like to see included please submit the idea over at: http://ideas.arcgis.com/ideaList?category=ArcGIS+Runtime.

2. You cannot manipulate the map object to add NEW layers connected to a database....or create layers on the fly and add features an then persist it....unless they are tied to a feature service.

This is possible, but requires you to work within the framework of Map Packages, local services and the "DynamicLayer" capability of these local services (see http://resources.arcgis.com/en/help/runtime-wpf/samples/index.html#/Add_Shapefiles_and_Rasters/02q20...) or perhaps might require you to create a custom layer type which derives from GraphicsLayer. The existing WPF SDK is very much a services-based API. However, the new .NET SDK is designed to function equally both online and offline and provides a more extensive API for local data access.

3. from my point of view (correct me if i'm wrong) an application developed under this technology is tied up to previously created content, and that content cannot be modified with the freedom that ArcObjects gave to us (developers), I mean...if i have a map package...i can add, in my application, other layer, but i cannot persist that addition; as well i can load feature packages...and modify the features inside of it, but i am not able of create those packages from my application, and then add them to the map package.

The new .NET SDK is designed to address these challenges - you'll have greater flexibility when working with geodatabases and layers locally.

4. maybe i'm searching in the wrong way, but i cannot find the way (in the product reference) to access to a Feature class in a file geodatabase or personal geodatabase

Currently this is achieved either via a local map service / local feature service (Personal Gdb not supported) or alternatively you can use geoprocessing and python scripting.

Why to deprecate ArcObjects if they provide such a big opportunity and granularity???

There are currently a few areas where the ArcGIS runtime does not match ArcObjects for functionality, but over the next few releases we'll see those scenarios met by equivalent functionality in the ArcGIS runtime. Until then you may need to continue some ArcObjects-based development but for migration of existing applications and any new applications I'd always encourage you to evaluate the runtime SDKs first.


The beta of the new .NET SDK will be out at the end of the summer, please give it a try and let us know what you think - we really appreciate all feedback.

Cheers

Mike

[GeorgeFaraj]

Hey Mike, just wondering, are we going to see a labeling engine added soon to any of the .NET SDKs?

[CharlesVan_Dusen]

Any update on when this SDK will be available for Beta and generally?

I am referring to the 'ArcGIS Runtime SDK for .NET'

TIA