Latest Contributions by dotMorten_esri

The issue is likely that the manage runtime can't find its native libraries if they aren't deployed in the same folder as your executable (which is likely the test runner and not your test library). You can try setting the InstallPath property on test startup to help it find it if you're using .NET Framework (If you one day move to use .NET Core / .NET 5, there's a different way to hint the runtime where native libs are to be loaded from) ... View more

Also just to rule WinForms in/out: If you just create a really simple WPF application (without WinForms) with those layers in a MapView, will it work on those machines? ... View more

Thanks. Things seem to look ok there. What sort of VM software are you using? (VMWare etc) Are they different between the working and non-working one? Also could you monitor each layer's LoadStatus property, as well as their LayerViewStatus? - https://developers.arcgis.com/net/api-reference/api/netwin/Esri.ArcGISRuntime/Esri.ArcGISRuntime.Mapping.Layer.LoadStatusChanged.html mapView.LayerViewStateChanged += MapView_LayerViewStateChanged; private void MapView_LayerViewStateChanged(object sender, LayerViewStateChangedEventArgs e) { Debug.WriteLine("*** LayerViewState : " + e.Layer.Name + " = " + e.LayerViewState.Status + " | " + e.LayerViewState.Error?.Message); } ... View more

If performance is critical, I wouldn't recommend using shapefiles. Instead I'd suggest you download the .gdb file from that source, open it in Pro and export that dataset to a runtime geodatabase, then use that instead. https://pro.arcgis.com/en/pro-app/2.7/help/data/geodatabases/manage-mobile-gdb/mobile-geodatabases.htm ... View more

Thanks for confirming. This definitely seems like a new issue I haven't encountered before. Can you share any extra information about the machines where it isn't working? Are they VMs? And do those VMs support DirectX ? You can try and run the command `dxdiag` (WIN+R) and the click "Save all information" to save a report on the system hardware. ... View more

When you run the app, do you see the "powered by esri" logo in the bottom right corner of where the mapview should be? Since both WinForms and RemoteDesktop require software rendering, I do wonder if there's an issue with not detecting this correctly. We can verify that by trying to force software rendering with the following line of code when the app starts up (before the mapview is created):     AppContext.SetSwitch("Switch.Esri.ArcGISRuntime.ForceSoftwareRendering", true); Which version are you using? (there's been several issues fixed wrt detecting software rendering being required) ... View more

What I'd suggest you do is split your unit tests into two: The ones you run on .NET Core only references  the 'Esri.ArcGISRuntime' nuget package, as this one is supported on .NET Core. These should be all your non-UI tests. The Forms package contains Forms specific types that are meant to be used in UI so you can use this in UI Tests which must be run on a device that we support forms on. Using the Forms libraries in a .NET Core application in U11 wasn't supported, isn't tested, and you could easily get you into runtime exceptions. > As for interfaces, yeah sure, it's technically a breaking change if someone implements IMapView and you change it, but I feel like it could be remedied by just putting a comment on the interface indicating that it will change over time Unfortunately it still breaks binary compatibility. If say you use a 3rd party library or plug-in that hasn't been compiled for v.next yet, you'd be stuck on the old version until all your dependencies have been updated. For .NET Maui, since we're only compiling that for .NET 6, we're going to solve that problem with default interface members, so it will be non-breaking there, and yes you'll get an IMapView interface with Maui (and we'll probably also tell you not to extend it).  > Additionally the fact that the Runtime is available as a .Net standard library would seem to imply that it should run in anything that supports .Net standard. That's kind of the main point of .Net standard That's not quite the case. .NET Standard ensures you have a common set of APIs to code against across many platforms. But it isn't a runtime, and there is no such thing as a ".NET Standard Application" (hence why you can only make .NET Standard class libraries). At the end of the day you still have to compile your application for a specific runtime. It's true that many .NET class libraries only relies on the runtime APIs provided by .NET, so they are usable on all the platforms .NET Core runs, but ArcGIS Runtime relies not only this, but also its own native runtime that is specifically compiled for each platform. Those runtime platforms today are win32, uwp, ios and android. In the next release we'll actually have our assemblies much more clearly attributed with platform support attributes, so you'd get proper warnings if you try and run this on a platform that isn't indicated as supported. .NET Core 3,1 itself actually supports running on many platforms, but again requires the correct runtime for that to work, and we've been quite clear that it was only Windows that was supported there. With .NET 5, it's a little more clear as the target is "net5.0-windows" and not just the base "net5.0" target, but that wasn't something we could do in 3.1, although it got implied by the WPF dependency it had (for U13 we hope to provide net6.0-windows, net6.0-ios and net6.0-android targets - we'll still provide a net6.0 reference assembly for compiling your cross platform business logic, but in the end, you'll still need to target a specific platform to run them). So bottom line: The netstandard target is really only supported for class libraries. For running applications, you much pick a supported platform, and .NET Core isn't supported with Forms. ... View more

If you just have a limited set of colors, I'd just use a UniqueValueRenderer instead of DictionaryRenderer. ... View more

> Graphic does have the Attributes property, but as far as I can tell it has no SetAttributeValue method? You can use: myGraphic.Attributes["fieldname"] = newValue; ... View more

This is currently not possible but is on our backlog to add. I've added your request to the backlog item. ... View more

Xamarin.Forms only supports the iOS, Android and UWP at runtime - it cannot be used with .NET Standard and has never been supported. The .NET Core target relies on WPF, and we have no Forms binding for WPF. If you need to run on .NET Core, you'll need to not reference the Forms package. > Why does ESRI not provide interfaces for the ESRI.ArcGISRuntime.Xamarin.Forms objects We don't provide interfaces for types that frequently evolve, as changing that interface would be a breaking change. ... View more

Try checking the LoadStatus of each layer in  your map and basemap. This might give you an indication what went wrong. ... View more

A few questions, just to clarify your scenario, so I can better suggest the most efficient approach: - Does all the ship symbols look the same (except for the direction they are rotated to) - If the symbols doesn't look the same, do every individual ship use a unique looking symbol, or are there limited set of symbols? (like rowboat, sailboat, ferry, freighter etc, and again ignoring the heading of each one). If they are all the same symbol, you should use a SimpleRenderer with a rotation expression set. If there is a limited group of symbols, use a UniqueValueRenderer with a rotation expression. If every single ship uses a completely unique picture marker symbol, I would suggest you reconsider your approach, or at least keep the number of ships displayed at the same time to a minimum. If that's the case, perhaps you can go into more detail how each ship changes (ie color, size, shape changing, or unique photo of each vessel, etc and also what sort of info you use to decide how they look different) ... View more

We have not been able to reproduce this behavior. Could you possibly create a sample that demonstrates the problem? Also which version are you using? ... View more

There is RuntimeImage.FromStreamAsync(stream) that you can use, but under the covers it unfortunately have to do the same thing, so you're really not saving much. I would however recommend trying JPEG or PNG so you reduce the byte-buffer size, and how much needs to be sent into the native library - while that will create a small overhead for encoding and decoding, it might overall create a small boost in less memory allocation and interop overhead. ... View more