Hi,No, the new ArcGIS Professional Application is not currently based on the new ArcGIS Runtime SDK for .NET.
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.CheersMike
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?
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?
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 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.
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???
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).
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.
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.
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.
Glad to hear that’s in the works. Ideally, I think the best solution for my application will be to provide a capability to read all supported raster formats, and, not unlike the “create pyramids” function, at the user’s discretion, generate the tiled map package at run time. This gives the user the flexibility to load a raster map on the fly, and also exploit the enhanced performance of the Local tiled map package, all without a dedicated server requirement.
Indeed, the raster support will include directly reading a number of common formats such as TIFF without the need for the LocalServer/LocalServices and without the need to create packages or tile caches. Pyramids will just be read as part of reading the raster data and will dramatically improve the performance.
I should clarify - the raster support is on the the roadmap for the ArcGIS Runtime SDK for .NET.
Retrieving data ...