I am trying to add and view a single feature layer from our service with the following code:
"http://orbittest.miner.com:6080/arcgis/rest/services/GRU_ElectricDistribution/MapServer/1", "Support Structure");
public void AddLayerFromUrl(string layerUrl, string name)
var layer = new FeatureLayer(new Uri(layerUrl))
Id = name,
Name = name,
IsVisible = true,
ScaleSymbols = false
The "Lines" layer displays fine in the map. The "Support Structure" labels appear, but the actual symbols / graphics do not. I have tried with ScaleSymbols set to true and false. I am using 100.5. I have reproduced this in the Sample App WPF provided by Esri.
See attached screenshot.
I also attached the json for the troublesome layer. Note that there are multiple layers on this service that demonstrate this behavior. I also attached the .json for Anchor Guy which is a simple layer that reproduces the problem.
Solved! Go to Solution.
Could you please try to use ServiceFeaturetable.UseAdvancedSymbology property and set to "false". I have seen few issues have been reported and adding that property makes symbology appears.
By default this property is true and this is applicable if you use only ArcGIS Pro Symbol.
Hope that helps. Thanks
Thanks! That fixed our specific issue.
However, how do I know, as a client app developer with my app distributed to various organizations if this should be set to true or false? For example, organization A does use ArcGIS Pro Symbology and organization B does not use ArcGIS Pro Symbology - if I hardcode this value to false then what happens to organization A?
Just so you know, this is just a workaround and we are aware of this issue. The development team is looking at this. The issue may be related with recent Windows update, but not sure at this moment. I will keep you posted to this thread what I find. Thanks
Be aware that some of our clients have started seeing the same issue. We'll likely ship this workaround to them as a temporary hot-fix. But, we'll be very interested in the version of Runtime that has the full fix.
Thanks for pointing that out. Unfortunately, we also see the behavior in iOS when using the Xamarin.Forms Runtime. Any thoughts for our next steps there? We've put in place the workaround, but don't know when we can remove it.
We're working closely with Microsoft to resolve this issue.
The current recommended workaround documented in the other thread is to remove the listed Windows Updates (KBs) from Windows servers that host services consumed by Runtime applications or Windows desktops where ArcMap is used to generate Runtime Content.