Latest Contributions by MichaelBranscomb

In ArcGIS Runtime SDK for .NET 100.6 we added a useful API enhancement that can improve the performance of your apps with the new Esri.ArcGISRuntime.RuntimeCollection.AddRange method. There are several classes in the API that derive from the base RuntimeCollection, making this method available on many commonly used types such as GraphicCollection, GraphicsOverlayCollection, LayerCollection, UniqueValueCollection, and ClassBreakCollection.   The AddRange method helps improve performance for your apps by batching internal ArcGIS Runtime logic related to error handling and collection changed events. Internal benchmark tests run by the ArcGIS Runtime SDK for .NET development team using BenchmarkDotNet to compare individual GraphicCollection.Add calls with the GraphicCollection.AddRange call showed a 10-15% reduction in execution time when adding large numbers of Graphic instances to a GraphicCollection (i.e. GraphicsOverlay.Graphics). Additionally there was a 85-90% reduction in temporary allocations which reduces the memory consumed and reduces the workload for garbage collection.    The two code snippets below show an example using the AddRange method, new at 100.6, and an example using the existing Add method.   AddRange method GraphicsOverlay graphicsOverlay = new GraphicsOverlay(); graphicsOverlay.Renderer = new SimpleRenderer(new SimpleMarkerSymbol(SimpleMarkerSymbolStyle.Circle, Color.CornflowerBlue, 10)); SpatialReference spatialReference = SpatialReferences.WebMercator; Random random = new Random(); List<Graphic> graphicList = new List<Graphic>(10000); for (int i = 0; i < 10000; i++) { Graphic graphic = new Graphic(new MapPoint(random.Next(0, 20000000), random.Next(0, 20000000), spatialReference)); graphicList.Add(graphic); } graphicsOverlay.Graphics.AddRange(graphicList);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Add method GraphicsOverlay graphicsOverlay = new GraphicsOverlay(); graphicsOverlay.Renderer = new SimpleRenderer(new SimpleMarkerSymbol(SimpleMarkerSymbolStyle.Circle, Color.CornflowerBlue, 10)); SpatialReference spatialReference = SpatialReferences.WebMercator; Random random = new Random(); for (int i = 0; i < 10000; i++) { Graphic graphic = new Graphic(new MapPoint(random.Next(0, 20000000), random.Next(0, 20000000), spatialReference)); graphicsOverlay.Graphics.Add(graphic); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   ... View more

Symbol files are now available for improved diagnosis of issues when working with ArcGIS Runtime SDK for .NET. Symbol files, or program database files (.pdb), link instructions in compiled applications and libraries to statements in the original source code. They enable you to access a more informative call stack if that application or library fails. Call stacks are valuable because they enable us to: Identify if the issue you are experiencing matches an existing issue in our backlog Determine if we have reproduced the same issue you have in your environment Gain more insight on where to look for the underlying problem If your WPF or UWP application crashes and the call stack points to the ArcGIS Runtime libraries, you can use either of the two workflows outlined below to provide Esri with more specific information and help us to more swiftly identify the cause of issue.  When debugging and working with symbol files you will see a distinction made between managed and native libraries ("modules"). Managed modules contain code whose execution is managed by the .NET Common Language Runtime. Native modules contain code whose execution is controlled by the developer of that library and as such is often referred to as unmanaged code. The UWP and WPF APIs within ArcGIS Runtime SDK for .NET each comprise one managed and two native libraries: Esri.ArcGISRuntime.dll: A managed library containing the .NET API types you reference RuntimeCoreNet.dll: A native library containing functional references to the ArcGIS RuntimeCore library RuntimeCore.dll: A native library containing the implementation for all ArcGIS Runtime core capabilities Add a reference to the Esri symbol server In Visual Studio, open the Options dialog (Tools > Options). In the Options dialog expand Debugging and choose Symbols. Click the ‘+’ button to add a new symbol file (.pdb) location. Enter the Esri symbol server URL: http://downloads2.esri.com/support/symbols. Ensure the checkbox is checked next to the new URL in the list of `Symbol file (.pdb) locations` and click `OK` to close the Options dialog. For more information see Specify symbol (.pdb) and source files in the Visual Studio debugger in the Microsoft documentation. Workflow 1. Debug the application Follow these steps if you can reproduce the problem when running your application with the debugger attached. In Visual Studio, click `Start Debugging` (or tap F5). Open the Modules window by choose Debug on the menu bar > Windows > Modules. Locate the module Esri.ArcGISRuntime.dll then right click and choose `Load Symbols`. Ensure the `Symbol Status` for the module is `Symbols loaded`. Run through the workflow that reproduces the problem. Open the Threads window by choosing Debug on the menu bar > Windows > Threads. Locate and select the thread showing the current execution point (indicated by a yellow arrow). If the current execution thread shows no references to ArcGIS Runtime then locate the faulting thread. Inspect for references to ArcGIS Runtime. Select the thread of interest in the threads window. From the menu bar, navigate to Debug > Windows > Call Stack to view the call stack for the thread. In the Call Stack window, right click and choose Select All then copy the selected text. If you see one or more calls to Esri.ArcGISRuntime.dll with lines similar to runtimecore.dll!00007ffdeb571164 this indicates the call stack continues into the ArcGIS Runtime native libraries and you must enable native code debugging to get more information. For more information see How to use the threads window in the Visual Studio documentation. Enable native code debugging In Visual Studio, open the Project Properties dialog and select the Debug tab. Under the section `Debugger engines`, check the box to `Enable native code debugging`. For more information see Enable mixed mode debugging in the Microsoft documentation. Debug the application with native code debugging   In Visual Studio, click `Start Debugging` (or tap F5). From the menu bar, navigate to Debug > Windows > Modules to open the Modules window. For each of the following modules, locate the module > right click > choose `Load Symbols`: RuntimeCoreNet.dll runtimecore.dll Ensure the `Symbol Status` for each module above is `Symbols loaded`. Run through the workflow that reproduces the problem. From the menu bar, navigate to Debug > Windows > Threads to open the Threads window. Locate and select the thread showing the current execution point (yellow arrow). If the current execution thread shows no references to ArcGIS Runtime locate the faulting thread. Inspect for references to ArcGIS Runtime. Select the thread of interest in the threads window. From the menu bar navigate to Debug > Windows > Call Stack to view the call stack for the thread. In the Call Stack window right click, choose Select All and copy the selected text. For more information see How to use the threads window in the Visual Studio documentation. Workflow 2. Debug a dump file Create dump file from your application process Run through the workflow that reproduces the problem. When the application crashes open Windows Task Manager > select the `Details` tab > locate the process > Right click > choose 'Create dump file'. On the `Dumping Process` dialog that appears, take note of the file location (select the path text and copy). Debug the Dump File In Visual Studio, navigate to File > Open > File. In the open file dialog, browse for and choose the <YourApplicationProcessName>.DMP file (or paste the path you copied earlier). On the Minidump File Summary page look for the collapsible Actions section. Choose `Debug with Mixed`. For each of the following modules, locate the module > right click > choose `Load Symbols`: Esri.ArcGISRuntime.dll RuntimeCoreNet.dll runtimecore.dll Ensure the `Symbol Status` for each module above is `Symbols loaded`. From the menu bar, navigate to Debug > Windows > Threads to open the Threads window. Locate and select the thread showing the current execution point (yellow arrow). If the current execution thread shows no references to ArcGIS Runtime locate the faulting thread. Inspect for references to ArcGIS Runtime. Select the thread of interest in the threads window. From the menu bar navigate to Debug > Windows > Call Stack to view the call stack for the thread. In the Call Stack window right click, choose Select All and copy the selected text. For more information see How to use the threads window in the Visual Studio documentation. If you have copied the text for an ArcGIS Runtime related call stack you can add this information to a Geonet post or provide it to an Esri analyst when you contact Support to report your issue. Example The following example shows the type of ArcGIS Runtime call stack you might have in the event of an crash and shows how you might read a call stack to decipher potential causes of the problem and perhaps find a temporary workaround. In July 2019 an ArcGIS Runtime user reported on GeoNet a crash with 100.5 when their code called the asynchronous method RouteTask.SolveRouteAsync(). They did the best thing you can do in this situation by attaching a simple standalone reproducer application to the Geonet post. It enabled the development team to repeat the exact workflow and get the call stack using the 100.5 symbol files. The call stack showed that ArcGIS Runtime code was failing within geometry spatial reference handling, which allowed us to recommend a straightforward workaround: specify the SpatialReference when creating MapPoint geometries to represent Stops. Now with 100.6, you too have access to the symbol files giving you a head start on identifying possible causes and temporary workarounds, and more specific information to share with us when reporting your issue. In this case, thanks to the excellent reproducer application from the user we were able to quickly diagnose and fix this bug for the 100.6 release. Example call stack: > runtimecore.dll!Esri_runtimecore::Geometry::Spatial_reference_impl::horizontal_equal_(class Esri_runtimecore::Geometry::Spatial_reference_impl const &) Unknown runtimecore.dll!Esri_runtimecore::Geometry::Spatial_reference_impl::equals(class Esri_runtimecore::Geometry::Spatial_reference const &) Unknown runtimecore.dll!Esri_runtimecore::Network_analyst::reproject(class std::shared_ptr<class Esri_runtimecore::Geometry::Geometry> const &,class std::shared_ptr<class Esri_runtimecore::Geometry::Spatial_reference> const &,class std::shared_ptr<class Esri_runtimecore::Geometry::Spatial_reference> const &) Unknown runtimecore.dll!Esri_runtimecore::Network_analyst::NA_utils::reproject<class Esri_runtimecore::Network_analyst::Stop>(class std::shared_ptr<class Esri_runtimecore::Geometry::Spatial_reference> const &,class std::vector<class Esri_runtimecore::Network_analyst::Stop,class std::allocator<class Esri_runtimecore::Network_analyst::Stop> > &) Unknown runtimecore.dll!Esri_runtimecore::Network_analyst::Local_route_task::initialize_stops_(class Esri_runtimecore::Network_analyst::Route_parameters const &,class std::vector<class Esri_runtimecore::Network_analyst::Stop,class std::allocator<class Esri_runtimecore::Network_analyst::Stop> > const &,class std::vector<class Esri_runtimecore::Network_analyst::Stop,class std::allocator<class Esri_runtimecore::Network_analyst::Stop> > &,class std::shared_ptr<class Esri_runtimecore::Geodatabase::Transportation_network_view> const &,class std::vector<struct Esri_runtimecore::Network_analyst::Solve_condition,class std::allocator<struct Esri_runtimecore::Network_analyst::Solve_condition> > &,class std::vector<struct Esri_runtimecore::Network_analyst::Solve_condition,class std::allocator<struct Esri_runtimecore::Network_analyst::Solve_condition> > &) Unknown runtimecore.dll!Esri_runtimecore::Network_analyst::Local_route_task::solve(class Esri_runtimecore::Network_analyst::Route_parameters,class pplx::cancellation_token const &) Unknown runtimecore.dll!Esri_runtimecore::Mapping::Local_solve_operation::solve_async(class std::shared_ptr<class Esri_runtimecore::Mapping::Request_delegator> const &,class std::shared_ptr<class Esri_runtimecore::Mapping::Route_parameters> const &,class Esri_runtimecore::Mapping::Task_completion_source<class std::shared_ptr<class Esri_runtimecore::Mapping::Route_result> >,class Esri_runtimecore::Mapping::Task_options) Unknown runtimecore.dll!<lambda_892f625b129cc43ba2b282eeb1ecc18f>::operator()<pplx::task<boost::any>>() Unknown runtimecore.dll!std::_Func_impl_no_alloc<<lambda_31388138151c3f34bc6c36ef59ef90df>,boost::any,pplx::task<boost::any>>::_Do_call() Unknown runtimecore.dll!std::_Func_class<class boost::any,class pplx::task<class std::vector<class boost::any,class std::allocator<class boost::any> > > >::operator()(class pplx::task<class std::vector<class boost::any,class std::allocator<class boost::any> > >) Unknown runtimecore.dll!pplx::details::_PPLTaskHandle<class boost::any,struct pplx::task<class boost::any>::_ContinuationTaskHandle<class boost::any,class boost::any,class std::function<class boost::any >,struct std::integral_constant<bool,1>,struct pplx::details::_TypeSelectorNoAsync>,struct pplx::details::_ContinuationTaskHandleBase>::invoke(void) Unknown runtimecore.dll!pplx::details::_TaskProcHandle::_RunChoreBridge(void *) Unknown runtimecore.dll!Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void *) Unknown runtimecore.dll!Esri_runtimecore::Common::Windows_Threadpool_scheduler::Scheduler_param::work_callback(struct _TP_CALLBACK_INSTANCE *,void *,struct _TP_WORK *) Unknown ntdll.dll!77597dc4() Unknown ntdll.dll![Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] Unknown [External Code] ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   ... View more