The history and future of the ArcGIS SDKs for .NET

When Microsoft announced Silverlight at the MIX conference in 2008, we quickly started to look at what this amazing new technology could do to enable .NET developers to build great web applications for ArcGIS Server.   Since both Silverlight and WPF were based on .NET and XAML, we were able to quickly port our Silverlight implementation to the WPF platform.   The SDK grew popular very quickly – we even won several awards.  When the new Windows Phone platform was announced in 2010, we had a prototype running on a phone within the hour of launch.  The parity between the platforms was amazing such that nearly 99% of the source code was shared across the three APIs.   This provided a consistent experience for .NET developers building ArcGIS Server clients across all three platforms.

As time passed, we enhanced the WPF API by adding a local server.  In essence it was a mini-ArcGIS Server embedded in your application, and using it was similar to using an online server. At the same time a new “ArcGIS core runtime” was built, which gave us a new hardware-accelerated, high performance rendering pipeline as an alternative to the managed display pipeline included with the WPF API since its inception.  This is why the Map control in the WPF SDK has an option to use “accelerated display” mode today.  We have found that many developers did not use this new mode, and it added some confusion to the SDK, since there were two rendering pipelines and they didn’t support the same things. But we didn’t want to break your existing code and stuck with it.  As a result, the new core runtime was considered second class, and most of the API still revolved around being a client to ArcGIS Server (which also explains the namespace “ESRI.ArcGIS.Client”).

In the past year, we have been hard at work, bringing the ArcGIS Runtime to the new Windows Store platform.  This platform provides a tight integration between native C++ and .NET libraries.  It enabled us to take advantage of and prioritize the new core runtime-based architecture as well as use new C# language features for doing asynchronous code.  It gave us a faster and cleaner API to code against.  In addition, lessons learned from other SDKs enabled us to improve the developer experience.  We heard your feedback that building MVVM style apps was difficult, and improved it. We heard you wanted to render datasets with a large number of features, and we can now make this possible.  And support for native code in Windows Phone 8 also means that this API can be shared between Windows Store and Windows Phone apps.  We were now building a brand new SDK.  It wasn’t just a “client” to ArcGIS Server, and while it looked similar to the Silverlight and WPF SDKs, it was notably different.

This year at the Developer Summit we announced the addition of offline capabilities in all the ArcGIS Runtime SDKs, including WPF. This meant we had to rely more on the core runtime itself, by adding capabilities to work with local data into what was essentially a server API, and it began to feel less natural.  The new Windows Store and Windows Phone APIs were already proving there was a better way to do this. So a radical idea started to form:  What if we made the new API for Windows Store and Phone available for Desktop developers as well?

The benefits were clear.  We would have three identical APIs, meaning you only need to learn one to build apps for the Store, Phone, or Desktop.   It also means we could prioritize the integration and use of the core runtime as a first class citizen, giving you a high performance, natural, and refined API to code against.  You will even be able to share your code between platforms, so you can build new apps across platforms more quickly.

However there were some drawbacks.  It would mean the current version of the WPF SDK would have major breaking changes.  Your code would not just work on the latest version, and it would require some effort to migrate existing apps to this new architecture.  Our desire to deliver a backwards compatible SDK would not be possible.

We also knew there was much more functionality we wanted to add in the future, and with the significant enhancements to core runtime for using data offline, it looked like a significant change in the API was inevitable.   Basically, we would have to break the current API.   So we had to make a decision:  Do our best to keep the WPF SDK as it is today and make breaking changes over time –or- make a clean break and create a single unified SDK across multiple .NET platforms optimized for using both core runtime and services.   In the end, we decided it would be best to introduce a refined, consistent, high-performance API earlier rather than later.  And the new enhancements to core runtime, such as offline map use which many people have been waiting for, will be introduced in the new SDK.   Personally, knowing the repercussions, this has been one of the hardest decisions we’ve made.  At the same time, I’m extremely excited for what we will release soon, and I’m confident you will love it as well.

So what does this really mean?

We will soon be releasing a new SDK, the “ArcGIS Runtime SDK for the Microsoft .NET Framework”.  You can use this SDK to build ArcGIS Runtime apps on Windows Desktop, Store and Phone.  While it is really three SDKs  – one for each platform – we view them as one product for doing .NET development with the ArcGIS Runtime.  The platforms themselves are different, thus some of your markup and code will be different, but you will be able to reuse a significant amount of code across platforms.   In fact that’s how we’ve built it – the vast majority of the source code is shared across all three platforms.

What does this mean for the WPF SDK?

We will continue to support the existing WPF SDK for some time.  We will still release updates, but they will not include any major enhancements.

What does this mean for my existing code?

While your code will not compile as is with the new SDK, in many cases, the majority of the work can be migrated easily.   Instead of an event-based API, we use Task with async/await, which will change your code flow and make it easier to read and maintain.   I encourage you to use accelerated display in the current WPF SDK, and become familiar with the Task approach for asynchronous programming, which will be available in the next WPF SDK.   This will ease your migration from the WPF SDK to the Desktop API in the .NET SDK.  Since we will be releasing both SDKs side-by-side you will also have some time  to move to the new SDK and eventually take advantage of the new features, such as support for taking maps and data offline and 3D.

When will the ArcGIS Runtime SDK for .NET be available?

It will be released later this year with other ArcGIS Runtime SDKs as version 10.2.1.   We also plan to provide a beta at the end of the summer to gather feedback on the new SDK.

Morten Nielsen
Lead Developer, ArcGIS Runtime SDK for the Microsoft .NET Framework

This entry was posted in Developer and tagged , , , , , . Bookmark the permalink.

Leave a Reply


  1. geoyogesh says:

    what about development status for silverlight platform… is it supported? or it is ignored completely?

    • rexhansen says:

      The development and support status of the ArcGIS API for Silverlight remains unchanged. It is still being enhanced and it is still supported. Due to the nature of the Silverlight platform, it cannot take advantage of the ArcGIS core runtime, and thus it remains a Web API, not a Runtime SDK.

  2. says:

    what about the arcgis api for wpf, the forerunner of wpf runtime? does it work for 10.2? still i can download the version 2.4. it’s the same dev and support status like the silverlight api?

  3. danielrouleau says:

    I think this will be a great change for the better for the development landscape as a .NET developer leveraging Esri technology. Thanks for the nice, detailed post about the changes to come and the decisions that led up to it.

  4. sfisher says:

    When will this be in Beta? and how does this affect the current ArcGIS Runtime SDK for Windows Store apps currently in Beta?


    • rexhansen says:

      We plan to provide a 10.2.1 beta release at the end of this summer (see answer to last question in the blog post). At this point, the ArcGIS Runtime SDK for Windows Store apps will remain available as a beta until the 10.2.1 beta release of the ArcGIS Runtime SDK for .NET. The ArcGIS Runtime SDK for .NET will include an API to build Windows Store apps.

      • sfisher says:

        Thanks Rex, So will the current ArcGIS Runtime SDK for Windows Store apps Beta make it to release, or just move to the newer ArcGIS Runtime SDK for .NET? Are the APIs of these two the same, and will code port easily?

        • sharpgis says:

          The API for Windows Desktop/WPF, Windows Store, and Windows Phone will all be the same. While there will be some differences between the platforms, the SDK will be more or less completely identical. What you will see in the Desktop API will actually be very close to what you can see in the Windows Store beta SDK today (but expect some renames and clean up since that beta). If you’ve played with it, you probably already know that it’s really not that different from the existing WPF API (at the user conference we were able to port a user’s app from WPF to the new SDK in less than 30 mins, but your mileage may vary). So when you’re asking if the Store Apps SDK will make it to release the answer is yes, but it will be as part of the .NET SDK, which essentially contains 3 SDKs inside it: Desktop, Phone and Store.

  5. shohei_kusano says:

    I have an on-going project using WPF SDK, and I don’t think I have an extra budget or time for additional development for migrating to the new .NET SDK. Do you know when the support for WPF SDK will be ended?


  6. geoyogesh says:

    Will there be free ArcGIS API or SDK going forward (Except Silverlight API)?

    • rexhansen says:

      We’d like to provide a consistent experience for licensing development and deployment of all Runtime SDKs. Watch for updates to our licensing plan in the near future.

  7. janne58 says:

    I saw the nice offline-demo in the Plenary session at DevSummit in March, and wondering if the new offline-capabilities (Search, Geocoding, Reversed geocoding and Routing) is included in coming release of ArcGIS Runtime SDK for .NET?

    I’ve been asked to present the offline-functions next month.
    Are samplecode and information on how it works, going to be published in near future?
    Thanks for the blog. It was a very good explanation.

    • rexhansen says:

      Yes, new offline capabilities in the ArcGIS Runtime will be available in version 10.2.1 of the ArcGIS Runtime SDK for .NET. In general, information on the use of offline capabilities presented in sessions at the Dev Summit and UC is valid. Samples and documentation for specific SDKs will not be available until 10.2.1 beta is released at the end of the summer.

  8. ptarmigan says:

    What’s the long term direction for COM-based ArcObjects/ArcEngine…? Will the Runtime SDK eventually replace it?

    • rexhansen says:

      There are no specific plans to replace ArcGIS Engine with the ArcGIS Runtime SDKs at this time. ArcGIS Engine remains a viable option for developers who need to utilize the breadth and depth of ArcObjects, and need to customize ArcGIS Desktop. While ArcGIS Engine and the ArcGIS Runtime SDKs share many common geospatial capabilities, the ArcGIS Runtime SDKs provide more coarse grained, simplified APIs. In addition, ArcGIS Runtime SDKs are designed to build lightweight, high performance apps across many modern platforms. The capabilities of the ArcGIS Runtime SDK will continue to be enhanced over time to accommodate for updates to the ArcGIS system and specific user needs, such as disconnected map use and 3D. Many of these enhancements will bring the ArcGIS Runtime SDKs closer to functional parity to ArcObjects.

  9. skutz says:

    In the context of its offline capabilities, will the “ArcGIS Runtime SDK for the Microsoft .NET Framework” be able to support access to non-traditional local data sources?

    Said another way, the current ArcGIS Engine Runtime/ArcObjects environment supports the Plug-In Datasource as a mechanism to present external, local data to the ArcGIS environment as if it is a supported source.

    Will the ArcGIS Runtime SDK be providing a mechanism to also access that same type of external, local data with the ArcGIS Runtime?

    Thanks for your insights,

    • rexhansen says:

      Good question. Yes, we are looking into providing an extensible framework to use data formats not supported natively by the ArcGIS Runtime. What are some of the data formats you’re interested in?

      • skutz says:


        Sorry for the delay. I had given up hope on a response, and was pleasantly surprised today to find that one is available. This is to respond to your follow-up question.

        Our commercial product is an MFC application written in unmanaged Visual C++ code. From an Esri perspective, it is an ArcGIS Engine Runtime application that uses the MapControl and PageLayoutControl only (along with the Plug-In Datasource). ArcMap is not used for our commercial product.

        The product uses a proprietary data model. The data is physically stored in a *.mdb file (Access database) and is loaded into an in-memory series of classes during execution. Some of the attributes held by the in-memory objects include XY coordinate locations (for points) and XY point collections for the polyline and polygon-type objects.

        We use the Plug-In Datasource as the “glue” that allows this proprietary XY coordinate data to be served up into an ArcGIS environment as various feature layers with point, polyline, and polygon geometries.

        It was the availability of the Plug-In Datasource that drove our decision to become an Esri Business Partner in the first place since it was the only viable offering we located at the time (circa 2002) that allowed us to preserve our product’s internal data model while also allowing it to participate in the broader environment of GIS-centric processing (such as display, selection, handling user interaction, page layout and printing, on-the-fly projections, and so on).

        For our purposes, the fact that the Plug-In Datasource provides a read-only access to the underlying data is not a problem. Our product code itself provides the editor capabilities needed to add/update/delete objects from the in-memory data model. The subsequent map refresh processing, among other things, triggers the various methods in the Plug-In Datasource to retrieve the modified data from the in-memory object model and package the now-modified information into the appropriate “read-only” Esri feature and geometry instances (which successfully reflect the effects of the user editing changes).

        I won’t try to go into more detail here. The following three Esri Incidents provide some examples of the types of situations we have encountered when using the Plug-In Datasource: Esri Incidents #1019325, #827902, and #264407. The entry for Incident #264407 dated April 05, 2003 2:40 PM contains a more detailed discussion of how we started using the Plug-In Datasource in the first place and also includes the name of the Esri staff person who originally helped us implement the Plug-In Datasource within the environment of our Visual C++ product code.

        I’m glad to hear that you are looking into providing an extensible framework that will be able to use data formats not supported natively by the ArcGIS Runtime.


    • paula@esri says:

      Scott – very sorry to post off topic but have been trying to reach you-
      -Paula Brown

  10. computer3141 says:

    How is ArcGIS Runtime related to ArcGIS Mobile? Will it be replacing it? Will there still be a mobile cache so you can update spatial data without having connectivity? Thank you for any assistance in clearing this up.

    • rexhansen says:

      ArcGIS for Windows Mobile does not use the ArcGIS Runtime. However, ArcGIS for Windows Mobile still provides a viable option for location based, high-precision mobile solutions built on Microsoft’s Windows Mobile platform. Much of the functionality available on the Windows Mobile platform is or will be available in the next generation of Microsoft’s mobile platform, Windows Phone. The ArcGIS Runtime SDK for .NET discussed in this blog post will include a Windows Phone API built on the ArcGIS Runtime. Similar to a mobile cache, the ArcGIS Runtime SDKs will support consuming and editing local data in a runtime geodatabase. This functionality is available (in beta) in the 10.2 release of many of the ArcGIS Runtime SDK (eg. iOS, Android, Java, Qt). Feel free to peruse the documentation on The ArcGIS Runtime SDK for .NET will include this functionality in a 10.2.1 beta scheduled for a December 2013 release.

  11. jbailey.spatialbridge says:

    Hi Rex,

    Will the SDK for Desktop/WPF support the Windows Metro interface, or will the SDK for Windows Store be the only one that supports it at the 10.2 release?



    • rexhansen says:

      Just to clarify, “metro” is a design style that can be employed when developing apps on any platform. Microsoft’s Windows 8+ operating system supports developing .NET apps on two different platforms, one for the desktop and other for the modern UI (previously termed “metro”). The ArcGIS Runtime SDK for WPF, available today, supports building WPF apps for the desktop. WPF apps can use the “metro” design style (eg. Operations Dashboard for ArcGIS). The ArcGIS Runtime SDK for .NET will include a Windows Store API to build Windows Store apps for the modern UI on Windows 8/Windows RT systems. The ArcGIS Runtime SDK for .NET will also include a Windows Desktop API to build WPF apps for the desktop on Windows 7 and 8+ systems. The ArcGIS Runtime SDK for .NET is scheduled for a 10.2.1 beta release in December 2013.

      • skulavik says:

        All eyes are on you guys (Esri) and a handful of others companies to show us what “modern” versions of the “dead desktop” apps will do. The writing’s on the wall that the traditional desktop PC, along with apps there, are a thing of the past. Moving a powerful and gigantic toolset like ArcGIS to smaller, more concise, yet still powerful platforms like Windows 8.1+, iOS, and Android is critical if you’re going to keep your product(s) alive into the future. Folks, that’s what this SDK is all about. Wake up and support Esri in this effort if you care about the future of Esri at all. It’ll be up to this SDK to show that the future of Esri on Windows will carry GIS into the future.

  12. mikeeber says:

    What about improved developer support? We have had one issue where ESRI code that returned data in 10.0 and is not in 10.1 has been in the hands of ESRI for weeks without any response for a fix. Improve the SDK all you want but if we have no support then it isn’t a usable platform.

  13. gowthamlife.g says:

    ArcGIS Runtime SDKs as version 10.2.1 will support ArcGIS API for WPF?

    • rexhansen says:

      We will continue to release the ArcGIS Runtime SDK for WPF over the next year to include fixes and updates to accommodate for changes in the online platform (ArcGIS Online, Portal, Server). Within that time, WPF developers should transition to using the Windows Desktop API in the ArcGIS Runtime SDK for .NET as soon as possible. The public beta of the ArcGIS Runtime SDK for .NET will be available soon.

      • jason53220 says:

        In VS2012, you can create a portable class library project to target Silverlight, WPF, etc…Is the new .NET SDK taking advantage of this?


        • rexhansen says:

          Good question… unfortunately no. The .NET SDK is built on a native libraries (C++) which are not readily supported in a PCL. In addition, the cross-platform support in PCL is too limited for managed portions of our API to effective use it.

  14. marieslako says:

    Do you have an updated time frame for when this will be released Rex? We are eager and excited to get our hands on it.

  15. arun_kanth says:

    Do you know if ARCGIS RUNTIME SDK FOR .NET would have the ability to interact with data stored in arcsde like desktop ?
    And when can i see the beta version of the sdk ?


    • rexhansen says:

      None of the ArcGIS Runtime SDKs have built in cross platform support for connecting directly to a relational database\enterprise geodatabase. We’ll need to consider how to handle in the future. At this point, you have two options:

      1) Use ArcGIS Server. Whether on-premises or local server (in desktop APIs), both provide access to an enterprise geodatabase, albeit via http.
      2) Use platform to extend the API. In general, use what the platform provides to connect to a relational database (eg ADO with .NET). Leverage our layer model in the ArcGIS Runtime SDK to display results. Granted, depending on the complexity of your data and level of support in the platform, this may not be tenable.

      And, although you’ve probably already found it, the ArcGIS Runtime SDK for .NET beta is available:

  16. tcboring says:

    When can we expect an update to the Silverlight API? The latest version (3.2) was released in December 2013.