In my brief look at runtime I don't see any means to directly access either a file or enterprise geodatabase without utilizing an ArcGIS Server or Portal/AGOL. That is possible with Engine.
There is no way to direct-connect to a File Geodatabase. You will need to author Runtime Geodatabases in ArcMap/Pro that are optimized for the runtime.
Alternatively you can use the LocalServer, but I would recommend going the runtime geodatabase way for performance reasons.
At the dev conference last year I asked if Runtime is to be the replacement to ArcGIS Engine. I was told that it is intended to replace Engine. Is that true or not? If true then when would we see the libraries that support direct access to the file and enterprise geodatabase. I have an application I would like to move forward with your modern code and the app does not require indirect geodatabase interaction via ArcGIS Server map services. Too much overhead in that.
Also, the Runtime docs indicate the runtime file gdb you recommend is intended for mobile devices. Is that true? Why can't runtime access the traditional file GDBs created from Desktop or Pro?
Does Runtime support direct access to an Enterprise Geodatabase?
The plan is to be equivalent in overall functionality: Ie that it can do more or less the same things Engine can and most people will be able to solve the same scenarios in Runtime that they could with Engine. However that doesn't necessarily mean at the fine-grained level like working with all the same formats.
In your specific case, from a functionality standpoint though, we have equivalence in the sense of a single-file geo-enabled database that can be shared with a simple file-copy (btw ArcGIS Pro is also able to read the runtime database format).
Engine is based on ArcObjects, which is COM based. Runtime is a much a leaner, meaner fighting gis machine built in pure Cross-platform C++, enabling it to run on many more platforms. However that will mean we won't have the full ArcObjects engine behind it either.
Looking for some guidance then. My app is simple in that it does coordinate translation from non-spatial data sources and targets the results to either a file or enterprise GDB. Is it possible to combine .net runtime and the desktop.net SDK to provide the direct connection to file and enterprise GDP? I would be using the runtime lib for doing projections and datum transformations. Desktop .net SDK to write to the gdbs. Windows controls for the UI. And maybe use the runtime map object to visualize the results. Goal is to have it all running without any arcobjects libs and be stand alone.
No need to interact with web map services except for the map display, if I do that. A nice to have right now.
I guess licensing might be trickey. Any ideas on that? Would the user require two licenses? Desktop and runtime?
I currently have the app running in AO but no map display.
Appreciate the help.
Can runtime directly read file and enterprise gdbs without working thru a map service? Engine provides that and I wouldn't consider that fine grained. DG
> Can runtime directly read file and enterprise gdbs without working thru a map service?
No runtime uses the Runtime Geodatabase format.
What I meant by 'fine grained' is "feature" vs "specific file formats in that feature".
I don't really understand what you mean by this:
> I would be using the runtime lib for doing projections and datum transformations. Desktop .net SDK to write to the gdbs.
When you say "runtime lib" I assume you mean the "ArcGIS Rutnime SDK for .NET". But then when you are talking about the "Desktop .NET SDK" do you mean ArcGIS Pro .NET SDK or the WPF-portion of the Runtime .NET SDK?
The Pro SDK relies on ArcObjects, so that wouldn't get you around that limitation, and yes it would likely be two licenses (however it depends on how you license and what license agreement you have).
My mistake. I meant ArcGIS Desktop .net SDK which would of course mean I would have to use ArcObjects.
So it looks like Runtime is all about building native apps that interact only with web map services or mobile geodatabases.
If a custom native app does not require map service interaction then arcObjects via ArcGIS Engine is the choice.
It seems ESRI's intent is that all custom apps be interacting with either AGOL or Portal. But that is not always necessary or affordable to customers.
Will ArcObjects ever get a rewrite so it is not COM based? Or will Runtime eventually achieve that goal?
Sorry about being unclear earlier. Thanks.
So it looks like Runtime is all about building native apps that interact only with web map services or mobile geodatabases. [... ] It seems ESRI's intent is that all custom apps be interacting with either AGOL or Portal.
That's not really true. There's for instance also support for a wealth of raster data formats, and shapefile/kml will be coming back very soon too, and we have more formats coming. We however have to focus on formats that will work cross-platform, as the runtime runs on much more than just Windows (the mobile geodatabases are based on Sqlite which runs pretty much anywhere).
Yes Portal is a big part of across the ArcGIS platform and runtime supports it fully. But that doesn't mean you have to use it.
That's highly unlikely - however many of the ArcGIS products have started using runtime components. For instance the projection engine and geometry parts are no longer COM based. It was rewritten for runtime and those components has then made it back into the rest of the system. You'll see more of that in future release. ArcObjects is a HUGE product though, and it's not feasible to completely replace in the near future.
Bottom line is that the goal is in the future most people will to be able to build the types of apps that you build today with Engine but by using the runtime. That might however include changing the workflow slightly or use a different file format. But we also want to enable you to build new types of apps that Engine isn't capable of (for instance the offline story with check-out/in data etc is very strong in runtime, as well as running on more than a desktop, now that mobile devices are so commonplace)
The v100 runtime release has been a major architectural release for us (3 years in the making), and it sets us up really good move towards that goal. However we weren't willing to wait with a release until we reached that goal (or to be more specific: most customers weren't willing to wait that long :-) ).
Rest assured we are listening in the forums what people are asking for, and the more we hear that people want support for file geodatabases, the more we'll consider doing it. So I'm not saying it won't ever happen (or that it will) - just that similar things can currently be done with a different file format, and therefore there are other features that might get prioritized first. Of course we'd like to give you every feature you could think of, but it's really comes down to simple cost/benefit/feasibility and the resources at hand.
We are fully aware that there will be some cases where Engine is a better choice, and there's nothing wrong with that. However in the future, there should be a lot fewer of those cases, and your feedback helps us close those big gaps.
So let me ask you this: Is there a reason why you can't use the runtime geodatabase format instead of file geodatabases (knowing that Pro also fully supports it) ?
Wrt Enterprise geodatabase connections, we're currently limited by the database libraries simply not existing for all the platforms we support. We are evaluating various ideas how this can be accomplished, either at a per-platform basis, or as a custom datasource plug-in model - however currently the story for enterprise databases is to connect through them via the server, which does add a lot of benefits too.
Retrieving data ...