nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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/

Najděte více příspěvků označených jako

Runtime SDK for WPF

Accepted answers

All comments

MarcoBoeringa

Is the new "ArcGIS Professional Application" as unveiled on this year's UC, and that seems set to replace the ArcGIS for Desktop applications (ArcMap, ArcScene etc.) entirely at the next major release, and as presented in this video:

Unveiling the new ArcGIS Professional Application

based on this "new" development platform (ArcGIS Runtime SDK for .NET)? All indications seem so... or am I wrong?

MichaelBranscomb

Hi,

No, the new ArcGIS Professional Application is not currently based on the new ArcGIS Runtime SDK for .NET.

Cheers

Mike

MarcoBoeringa

Hi,

No, the new ArcGIS Professional Application is not currently based on the new ArcGIS Runtime SDK for .NET.

So it is still using ArcObjects, just with the added capabilities of .NET Framework 4.5, the Task based async functionality, Visual Studio 2012 support like 10.2, and a new redesigned user interface?

"Not currently", does that mean there are (possibly quite far in the future) plans for a migration / integration?

MichaelBranscomb

Hi,

The new ArcGIS Professional App is the next generation of ArcGIS for Desktop and is an out-of-the-box, end-user GIS application.

The new ArcGIS Runtime SDK for .NET is, as you summarized, a developer SDK based on .NET 4.5, extensively uses the new Task-based async functionality of .NET 4.5, and supports development in Visual Studio 2012.

I hope that clarifies the role of the two products.

Cheers

MarcoBoeringa

I wasn't confused about the primary roles of "ArcGIS Professional Application" and "ArcGIS Runtime SDK for .NET" as desktop end-user application and software development platforms respectively.

Just wondering - and this is probably an outrageous(!) thought at the moment considering the differences - whether ArcObjects would at some time be superseded by the ArcGIS Runtime as the main development platform for desktop applications, and would even form the basis of the main out-of-the-box, end-user application, "ArcGIS Professional" or whatever it would be called by then...

MichaelBranscomb

Hi,

Yes, if you are planning to undertake the development of a new custom desktop application then you should look at the ArcGIS Runtime first. There are still some areas where it does not offer the functionality of ArcGIS Engine, such as 3D visualization, but we will be doing our best to close that gap over the next couple of releases. It might be the case that your timescale is short, in which case you may need to continue to use ArcGIS Engine but you should consider ways in which you could architect your application that will ease your migration to the ArcGIS Runtime in future. Unfortunately I don't know the extensibility plans for the new ArcGIS Pro app.

It's too early to say, but the ArcGIS Professional App might use some components of the ArcGIS Runtime - just as the current ArcGIS for Desktop already does for 64-bit Geoprocessing.

Cheers

Mike

BrianMulllins

Will there be a better way to rotate graphics on an accelerated display map in 10.2 or beyond? I'm aware of the UniqueValueRenderer and ClassBreakRenderer options for rotating symbols but that approach didn't work well for our application. The main thing holding us back from being able to take advantage of the accelerated display is the fact that we cannot rotate graphics containing PictureMarkerSymbols.

Are there any plans in 10.2 to add in support for an animation system for graphic/symbols in the accelerated display? We are currently using the non-accelerated display so that we can use WPF animations on our control templated graphics.

MichaelBranscomb

Hi,

For the existing WPF SDK we're currently investigating adding both rotation as defined in a feature service (i.e. on a renderer) and also rotation directly on a symbol. We hope to include this in the next release but we're concerned about the performance implications in the non-accelerated display mode. It will be in the new Windows Desktop API as part of the ArcGIS Runtime SDK for .NET, which only uses the core runtime map rendering.

Regarding animation in the core runtime map (accelerated display mode in WPF), it is on the roadmap and we're aware that it's a significant requirement for many folk developing with the WPF SDK, but at this time is unlikely to be in the next release (10.2.1).

Cheers

Mike

GeorgeFaraj

Hi Mike,

Will there be a 10.2 release for the ArcGIS Runtime SDK for WPF prior to the transition to the new ArcGIS Runtime SDK for .NET? If so, when is that scheduled?

Thanks,
George

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/02q20000004z000000/) 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

MichaelBranscomb

Hi,

Release dates are always subject to some degree of change, but for the first full beta we are targeting end-Feb/early-March and the initial release is likely to be summer. There will be multiple Tech Workshops and Demo Theatres on the new SDK at the forthcoming Dev Summit in Palm Springs (and available after the event online).

Cheers

Mike

charlesroberts3

I hate to dredge up an old thread, but I still cannot see how the new Runtime SDKs (I'm using .Net desktop) supports even the most rudimentary capability to allow an end user to load a raster product of their choice (of course limited to the set of supported formats) and simply display it as a raster without needing to perform a pre-processing step in ArcMap or Desktop. I have a customer who would like to be able to load say, for example, geotiff or ADRG products as they see fit. My temporary work-around has been to produce tile package format file using ArcMap, which can be loaded from disk files, and in fact work pretty well in terms of load and render performance, however, I have had to hand wave so far as to how they will be able to use other raster products at run time. So far addressing this question to support via my sales rep has come back with yes, it is possible with a standard level license to do this with the local server component. Please could you describe to me exactly how this is supported.

charlesroberts3

Well since posting, I've found the Dynamic Service Layers Add Data sample, and I can load my .tif files. I will need to further investigate how make sure I'm using the pyramids or overviews, but it's a good starting point.

Thanks,

Charles

final_logo_only.png

MichaelBranscomb

Hi Charles,

Glad you have made progress adding raster/image data using DynamicLayer capability of the LocalMapService. It is worth bearing in mind that we are working on improved support for natively reading raster data as a first class layer type e.g. a "RasterLayer". We're expect to be able to include that in the next major release.

You might also like to consider investigating KML GroundOverlays as an option.

Cheers

Mike

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.