Latest Contributions by dotMorten_esri

This is a known limitation in the geometry engine. From https://developers.arcgis.com/net/api-reference/api/netwin/Esri.ArcGISRuntime/Esri.ArcGISRuntime.Geometry.GeometryEngine.html :   > GeometryEngine generally operates in two dimensions; operations do not account for z-values unless documented as such for a specific method (for example Project(Geometry, SpatialReference) will transform z-values in some cases).   ... View more

This post seems to indicate it is related to your signing certificates: https://stackoverflow.com/questions/66029781/appcenter-ios-install-error-this-app-cannot-be-installed-because-its-integrity ... View more

The only thing you get with the VS2019 installer is a set of simple starter templates and/or a set of local nuget packages (which are also available on nuget.org). You can still for instance in VS2017 create a new WPF project and manually add the Esri.ArcGISRuntime.WPF nuget package from nuget.org to your project. Having said that, VS2013 is quite old and I'm fairly certain it doesn't support the features required for our nuget packages. ... View more

The only ports that are used are http (80) and https (443). If moving to a different subnet fixes the issue, I don't think your issue is related to the runtime specifically, but a system settings issue. There's nothing "fancy" in the runtime itself. It's just standard HttpClient web requests being made. ... View more

Yes MAUI is on our roadmap, and we already got some of that work completed. We actually planned to ship the support with Update 13, but Microsoft's MAUI timeline has recently slipped to Q2 next year, and so we have to delay the release as well. We hope to fully support it as soon as possible after .NET MAUI ships in its final form, depending on how theirs and our release timelines align. We do plan to add .NET 6 as well as WinUI support in Update 13, which would allow you to build your own MapView handlers for MAUI if you can't wait. We _might_ (no promises) ship a preview for Maui for you to try out around the same time, or shortly thereafter. ... View more

Thank you! Much appreciated. I'm able to reproduce the issue and will log a bug for this. I think I might know what the problem is. Hopefully we can address this for the next release.   ... View more

When you say the layer view state even is giving 'null' what do you mean? You should be getting events for each layer, and there is a status as well as potentially an error object. The status is the most interesting thing. My guess is the spatial reference of your WMTS service doesn't match that of your basemap, and tiles services doesn't support reprojection. The view state should tell you if that is happening. You can also try to remove the basemap and only have your WMTS layer, so that the map would assume the spatial reference of your WMTS layer instead. https://developers.arcgis.com/net/api-reference/api/netwin/wpf/Esri.ArcGISRuntime.UI.Controls.GeoView.LayerViewStateChanged.html https://developers.arcgis.com/net/api-reference/api/netwin/Esri.ArcGISRuntime/Esri.ArcGISRuntime.Mapping.LayerViewStateChangedEventArgs.html ... View more

The Name property is on the parent class. It just looks like the inspector window for some reason isn't showing the parent class. Or it could be the iOS Linker purging it if it isn't being used. ... View more

First check the load status of your layer (or just call `await layer.LoadAsync()` ) and inspect the error (if there is one). If it loads fine, check the LayerViewState for the layer on the MapView instance. ... View more

Interesting comparison, and I agree QT is a bit of a surprise. I'm not an expert on the Java and QT code, but just looking over the .NET code and the general approach taken, I do have a few initial thoughts about this comparison: First calculating the convex hull and area is all performed in native code, and all 3 uses the exact same native binary for this calculation, so there should be absolutely no difference in the actual calculation. The only difference would be in creating the geometry objects and sending them into that native library. The overhead here would mostly be on the managed languages like Java and .NET, so QT being that much slower makes me wonder what we're actually measuring. Second, only running 5 times, and picking the best one doesn't say much. When we do performance tests, we typically run them 1000s or often 100s of 1000s times, doing warm up runs, pre-runs to understand how they roughly run to estimate how many runs we really need, measuring each run, removing extreme outliers, and also consider the standard deviations for interpretation. With only 5 runs, we can't say much about the standard deviation, and if the standard deviations are very large (say 10+ seconds for instance), you can't really reason that the above results are actually different. It could just be .NET got lucky, and QT got unlucky. Also we turn off all unnecessary apps and services, disable anti virus etc, since they can have a huge impact on the results. It could for instance be QT tests were running while a scanning tool was being busy. Again the standard deviations and LOTS of runs at different times would help you determine that. Also when you rely on random input data, you're not really comparing apples to apples - .NET could just have gotten lucky here and getting easier calculations, and you helped that by only picking the best of the 5 runs. Specifically for .NET (and probably the others), I would remove all calls to Console.WriteLine / Debug.WriteLine.  That can actually a rather expensive call and I assume not something we want to measure here. There are a bunch of various other minor optimizations that could be applied, but again it's all about what you're trying to measure. For instance you're also measuring the performance of getting a random number, and that could be different on each platform as well. For .NET the DateTime object isn't good for performance measuring. Usually you should use the HighPerformanceTimer APIs instead. You should be able to re-use the QueryPerformanceCounter API on all 3 platforms for instance.  As a simple change, it might be better to measure the time spent on a single run instead of all 100,000 combined (and using a high performance timer API to measure), then get the average and standard deviations for each. The distribution of each run might tell you a lot more. And often it might be worth breaking down what you measure into smaller pieces, so measure polygon creation as one test, convex hull calculation as another, area calculation is a 3rd etc. As mentioned first, the main difference between the 3 APIs would the object creations, and not so much the geometry engine calls. ... View more

By local data I meant a Tile Package TPK, Vector Tile package, map package, shape file or similar. ... View more

Any chance you could share a small simple xunit sample project that uses the runtime and demonstrates the problem? I'd like to see if we can't make this a bit easier, or work with the xunit team if something here is missing. ... View more

  ArcGISRuntimeEnvironment.InstallPath = Environment.CurrentDirectory;   The path should be to where the arcgisruntime100.x folder is, not current directory (we already search current). With .NET Core 3.1 and .NET 5+ you'd instead use the DllImportResolvers to help hinting at where libraries are located. However this might not be necessary, as these targets uses a built-in way to get the runtimes deployed that .NET Framework doesn't have, so things "might just work". Example:    System.Runtime.InteropServices.NativeLibrary.SetDllImportResolver(typeof(Esri.ArcGISRuntime.ArcGISRuntimeEnvironment).Assembly, new System.Runtime.InteropServices.DllImportResolver(DllImportResolver)); // ... private static IntPtr runtimeLibPtr = IntPtr.Zero; private static IntPtr DllImportResolver(string libraryName, Assembly assembly, System.Runtime.InteropServices.DllImportSearchPath? searchPath) { if (libraryName == "RuntimeCoreNet.dll") { if (runtimeLibPtr == IntPtr.Zero) { System.Runtime.InteropServices.NativeLibrary.TryLoad(@$"installpath\client{(Environment.Is64BitProcess ? "64" : "32")}\RuntimeCoreNet.dll", out runtimeLibPtr); } return runtimeLibPtr; } return IntPtr.Zero; }     ... View more

If the issue was due to the sub network, I don't think we'd have seen a successful load of the layers. Since they appear to load fine, I'm guessing this isn't a network issue, but could perhaps be confirmed by trying to load some local data instead. The fact that the layer view state is never changing, seems to indicate to me that the map view never starts up drawing. ... View more