|
POST
|
Hi @ZhouYi. Glad that solution works. With respect to your questions: 1) Yes, many developers make use of API Keys and the Location Platform basemap services (and so use this constructor). It's a popular way to enable access to our high quality up-to-date basemaps (and other location services) for apps where the app users do not sign in with an ArcGIS Online or ArcGIS Enterprise account. 2) Since 2022, many developers have been required to use our modern, metered basemap services through Location Platform. You can learn more about this requirement and our full terms of use here. In short (though please read that page for full details): if your application does not require your users to sign in with their ArcGIS Online or ArcGIS Enterprise account, then this most likely applies to you. In that case, API Keys are the appropriate way to access those basemaps. Bear in mind that you get a generous free basemap allowance. If you are building an application for ArcGIS Online or ArcGIS Enterprise users where those users will sign into the app with their ArcGIS account, then you might not need to use API Keys. In that case your app can enable basemap access for those users by allowing them to sign in with their ArcGIS account.
... View more
yesterday
|
0
|
0
|
19
|
|
POST
|
Hi. That constructor is marked as deprecated. You should use this instead, and set the Map's initialViewpoint or the MapView's viewpoint (see this tutorial). You'll need to convert your zoom level 5 to a scale value (see this tool). Please let us know if you still see the issue with that constructor.
... View more
Wednesday
|
1
|
3
|
86
|
|
BLOG
|
This blog post details our plans for modernizing and streamlining the ArcGIS Maps SDK for .NET at our next major release (300.0), coming in Q2 2026. This will allow us to deliver performance improvements, to better support modern .NET development patterns, and align us more closely with Microsoft’s developer roadmap. With that in mind, the following technologies are deprecated in ArcGIS Maps SDK for .NET 200.8: .NET Framework .NET Standard UWP x86 support on Windows (win-x86) This means that the last version of ArcGIS Maps SDK for .NET to support these technologies is 200.8 (including all 200.8.x long-term support patch releases). ArcGIS Maps SDK for .NET 300.0 and later will not support them. If you haven't already done so then you will need to address the following before you can upgrade to ArcGIS Maps SDK for .NET 300.0: If you're still building with .NET Framework, you should update your projects to use .NET 9 or later. If you're using UWP to build Windows apps, you should migrate to WinUI. If you're building 32-bit Windows apps, you should update these apps to 64-bit. It’s important to reiterate that the 200.8 long-term support release of the ArcGIS Maps SDK for .NET will continue to support these deprecated technologies until its retirement in 2030, giving you plenty of time to update your projects if you’re not quite ready to do so now. However, in general the barriers to updating your projects are low, and we encourage you to migrate your projects away from these technologies. Some of you may have previously assessed moving from .NET Framework to .NET, or to upgrade your 32-bit x86 Windows projects to 64-bit, but found at the time that your project dependencies might not support that move. A lot has changed in the last few years, so if you haven’t re-assessed that lately, we encourage you to take another look. There are many great resources available that cover these migrations. Here are some handy links: Esri Developer Summit 2023: Maps SDK for .NET Building Apps Esri Developer Summit 2022: Maps SDK for .NET Building Apps Pt 2 Microsoft documentation: Porting from .NET Framework to .NET Analyze before porting Upgrade WPF to .NET 8 Migrate from UWP to Windows App SDK (WinUI) If you're still on the fence about updating from .NET Framework to .NET, now is a great time to get that done using the current 200.8 SDK.
... View more
2 weeks ago
|
2
|
2
|
260
|
|
POST
|
A Lite license is all you'll need (it's free). While you're developing you typically don't use a license, and you see the "Licensed for developer use only" watermark on your map. When it comes time to deploy, you need to use a license. You can learn more here: https://developers.arcgis.com/net/license-and-deployment/
... View more
3 weeks ago
|
1
|
0
|
246
|
|
POST
|
Feature Collections are also a great solution, and mean you can put your data anywhere in the operational layers stack (rather than drawn above it, as the graphics overlays are). Just a couple of things to bear in mind: While you can initially populate a FeatureCollectionTable at the Lite license level using one of these constructors, making subsequent changes to those features (adding, editing, or deleting features) uses the editing APIs, which will require a Basic license. FeatureCollectionTables are schema-based, defining the fields expected for each feature, whereas GraphicsOverlays don't require that. This could be a good thing or not. But as Morten mentioned, clustering is supported on Graphics Overlay for point graphics, so perhaps that'll provide what you need.
... View more
3 weeks ago
|
1
|
2
|
282
|
|
POST
|
The simplest way to do this is to add Graphics to a Graphics Overlay. See this sample: https://developers.arcgis.com/net/wpf/sample-code/add-graphics-with-renderer/ Look at the MakePointGraphicsOverlay() method. A Graphic combines a geometry (in this case point) and optionally attributes, and can provide a symbol to determine what it will look like on the map (although you can optionally define a renderer on the Graphics Overlay to provide the symbol, which is what this sample does).
... View more
3 weeks ago
|
0
|
5
|
401
|
|
POST
|
Hi @ZheWang66369 There's not really enough information here to know what might be going on. Does your app use feature services or local data files, for example? Does the app tear down the MapView at any point or swap out the Map? However, the more important issue here is that 100.11 is retired (see the Product Life Cycle). You should really upgrade to the latest long-term support 100.15.6 release, which will contain many bug fixes and security updates over the version you are using. Longer-term you should migrate your app to the ArcGIS Maps SDK for Swift. Please update your app to a supported version of the SDK and see if this issue still occurs.
... View more
3 weeks ago
|
0
|
0
|
130
|
|
POST
|
I'm not an expert in this, but I think the file that does NOT have embedded SR will need both the XML auxiliary file AND a world file (which positions/scales the image). See this gist for an example, including some links at the bottom that talk some more about aux and world files.
... View more
09-26-2025
01:51 PM
|
0
|
0
|
199
|
|
POST
|
In addition to what @SomeGISGuy said above, since you mentioned creating a gallery, there is also the ArcGIS Maps SDK for .NET toolkit, which includes an open-source Basemap Gallery component.
... View more
09-26-2025
11:22 AM
|
0
|
0
|
245
|
|
POST
|
Hi @RTC The postscript is purely about the API Key capabilities introduced at ArcGIS Enterprise 11.4 (see link). If you're seeing that an API Key is invalid, it means it's not scoped to access the services you're using it for. For basemaps, simply follow the instructions here. API Keys can be created by either an ArcGIS Online account or an ArcGIS Location Platform account, but the important thing is to ensure that they're scoped for the service you want to access. Follow the instructions above to create an API Key and it should by default include Basemaps styles service access (which is what's needed for the service you're hitting.
... View more
09-18-2025
08:03 PM
|
0
|
1
|
382
|
|
POST
|
Hi. This is likely not a licensing issue. API Keys don't impact licensing at all. They just provide access to services. Here's what I think is happening: I am taking a guess, but I expect that when you use an API Key, you are setting it globally on ArcGISEnvironment. When that happens, the SDK blindly uses that API Key across the board and doesn't even try the AuthenticationManager workflows, which are responsible for getting suitable access tokens for various services - in this case your logged-in user's access token via OAuth which will confer access to those web maps. To use both API Keys and named user access tokens, one brute-force approach is what you're doing now - you unset that global API Key, and the SDK will then get a token for the user in question, which of course gives them access to their web maps. A more refined approach might be to set the API Key specifically on the Basemap objects you create in code, and not at the global ArcGISEnvironment level. The key there is that Basemap implements APIKeyResource (scroll down to see which classes support this). Here's the full list of API classes that are APIKeyResources: This means you can specifically set an API Key on any of these, which will take precedence over any other token we might have (or try to get hold of) for that item through AuthenticationManager. If an API Key is NOT set, then the SDK will use AuthenticationManager. You could even use separate API Keys for RouteTask, LocatorTask, and Basemaps you create in code if you wanted, and the SDK will then fall back to AuthenticationManager for everything else. In a little more detail… when determining which access token to use for a remote resource, the SDK follows this logic: Does the object (e.g. RouteTask) have an API Key set on it explicitly? If so, use that. If not, is there a global API Key set on ArcGISEnvironment? If so, use that. If not, let's ask AuthenticationManager for an access token (e.g. OAuth, or your custom authentication challenge handler, etc.). Hope that helps. P.S. When I talk about API Keys above, I mean in the context of Location Platform and ArcGIS Online; the Native Maps SDKs do not yet support ArcGIS Enterprise API Keys.
... View more
09-18-2025
09:44 AM
|
0
|
2
|
415
|
|
BLOG
|
We’re pleased to announce a special ArcGIS Runtime SDK for Android 100.15.7 patch release, adding 16KB page size support. Follow the Install and set up instructions or download the release here. This release is key for customers still using the ArcGIS Runtime SDK for Android in apps in the Google Play Store. From November 1, the Google Play Store will reject app updates that do not include 16KB page size support for 64-bit Android 15 devices. Even if developers are not planning further updates to their ArcGIS Runtime SDK for Android apps, they should consider adopting this patch release to ensure that users are not presented with a “page size compatible mode” alert whenever their apps are run on 64-bit Android 15 devices or later. Please note: This 100.15.7 patch release inherits the product life cycle of all 100.15.x releases: currently in Mature Support and entering Retirement on September 1, 2027. We recommend that developers using ArcGIS Runtime SDK for Android familiarize themselves with the product life cycle for the ArcGIS Runtime SDKs and plan to migrate their apps to ArcGIS Maps SDK for Kotlin. For those developers already using the ArcGIS Maps SDK for Kotlin, 16KB page size support was added in version 200.7 in April 2025.
... View more
09-17-2025
06:16 AM
|
3
|
0
|
642
|
|
POST
|
Excellent! Seems there's always another way to break things. Glad that was it, because otherwise I was out of ideas 🧐
... View more
09-05-2025
10:38 AM
|
1
|
0
|
517
|
|
POST
|
Yes. That's correct. I still think the "forbidden" error is coming from the service (in contrast to us locking the API by license level). Has your mobile worker's Role been modified to disabled Network Analysis?
... View more
09-05-2025
10:13 AM
|
0
|
2
|
521
|
|
POST
|
Hi @RTC. To clarify… there are two things being discussed here: Routing (creating turn-by-turn directions using the RouteTask API and the World Routing service or an MMPK) Navigating (following along the route, getting real-time guidance, using the RouteTracker API) There are also two other things that you talk about that are a bit muddied above: Licensing the SDK (Lite, Basic, Standard) Accessing the World Routing Service (with an appropriate access token) There's no licensing restriction to use the World Routing service or an MMPK to calculate turn-by-turn directions (Routes). However, you will need an appropriately scoped access token to use the World Routing service. To use the RouteTracker API for interactive navigation, you need a Basic license unless you are using the World Routing Service, in which case Lite is sufficient (when you pay Esri for the route calculation, that includes use of the RouteTracker API). That's covered in the Lite section of the Licensing and Capabilities table: Navigate a route using the RouteTracker API and ArcGIS location services. If you're using an MMPK (or some other routing service), then you need a Basic License to use the RouteTracker API. That's covered in the Basic section of the Licensing and Capabilities table: Navigate a route using the RouteTracker API and any ArcGIS routing service, or a network dataset that is stored locally on the device. So yes, Mobile Worker user type will allow you to use the interactive navigation guidance capabilities of the RouteTracker API with any service or local network dataset. But if you're using the World Routing service, you can even use the RouteTracker API with a Viewer user type. But: either way you need to make sure you have an access token for the World Routing service. I suspect that the "forbidden" error is because the access token you're using is not properly scoped (perhaps it just includes basemaps?). See this tutorial on selecting privileges. Hope that helps!
... View more
09-05-2025
08:21 AM
|
0
|
4
|
538
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | Wednesday | |
| 2 | 2 weeks ago | |
| 1 | 3 weeks ago | |
| 1 | 3 weeks ago | |
| 3 | 09-17-2025 06:16 AM |