Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

1124
14
07-12-2021 10:26 AM
TroyAvery1
New Contributor II

Assembly: Esri.ArcGISRuntime (in Esri.ArcGISRuntime.dll) Version: 100.11.0

https://developers.arcgis.com/net/wpf/api-reference/html/P_Esri_ArcGISRuntime_ArcGISRuntimeEnvironme...

Has anyone noticed that the documentation lists "InstallPath" as a property, but the assembly decomposition does not show it?

(Assembly Esri.ArcGISRuntime, Version=100.11.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86)

Is the runtime still capable of shared deployments?

We run our deployment pointing to a shared location for a couple of different applications.

0 Kudos
14 Replies
MarkCederholm
Regular Contributor II

Good point; I went ahead and moved those lines to the end of the block.  I still am seeing both issues, however.

0 Kudos
TroyAvery1
New Contributor II

Actually, I don't think "moving to the end" is enough. With the discovery stuff I've seen it will discover them at the beginning of the method.  

I did a similar plug-in discovery project that couldn't be referenced until paths were defined and basic init was done. I had to move all the specific stuff to methods that were only used post init, and I couldn't use any "using" definitions.  If you did it would blow up.  Of course, that was before we started compiling it with the delayed load flag active so I don't know how much of it was caused by that.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

@TroyAvery1 It shouldn't. Just touching the managed assembly should be fine. Most types however that are backed by the native bits of runtime would cause a load of the native lib, so just try and avoid creating any objects, or calling any static methods in the assembly until you've initialized stuff.
Also note that the import resolvers only apply to loading the native assemblies - it does not relate to loading of the resources (ie shaders and other resources). Those are usually expected to still be located in the application folder together with the managed assemblies.

0 Kudos
TroyAvery1
New Contributor II

Yea, the plugin work I was referencing was not in any way related to ESRI, I was just quoting some experience in similar things.  It ended up having to look like:

 

public static ManagedInitializer()
{
   try {
      //do bunch of init stuff (path, assembly load, etc)

      //This call would cause exception on entry into "ManagedInitializer()"
      //Some.Dynamic.Load.Library.BusinessLogic();

      //where this would be totally fine......
      DoTheActualWork();

   } catch (Exception) {
      //Somethng messed up
   }
}

private static void DoTheActualWork()
{
   string result = Some.Dynamic.Load.Library.BusinessLogic();
}

0 Kudos
dotMorten_esri
Esri Frequent Contributor

Just following up on this: The reason you weren't seeing InstallPath in the assembly but in the doc, was that the doc was showing the .NET Framework version, and not the .NET Core version which uses a very different built-in mechanism for loading native runtimes. The doc site got updated with U12 so you can switch between all supported target frameworks, and there's also a table showing which platforms a given member is available on. (expand the "applies to" table here: https://developers.arcgis.com/net/api-reference/api/netfx/Esri.ArcGISRuntime/Esri.ArcGISRuntime.ArcG... )

0 Kudos