topic Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath in .NET Maps SDK Questions

Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

TroyAvery1 — Mon, 12 Jul 2021 17:26:26 GMT

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

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

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.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

dotMorten_esri — Mon, 12 Jul 2021 17:38:48 GMT

I'm assuming you're targeting .NET Core/.NET 5 and not .NET Framework? Unfortunately our documentation doesn't show doc for both (we're actively working on that - stay tuned!), but the property is only available with .NET Framework, since there's now a newer better way to load native libraries dynamically than .NET Framework provided.

If you can share your scenario for setting this property, I can help provide you with some equivalent code in .NET Core / NET 5.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

TroyAvery1 — Mon, 12 Jul 2021 17:46:55 GMT

Yes, this is part of a transition for a .NET Framework to .NET 5

Our previous usage was fairly simple, we created an installer for the shared items and then in the consuming application before we begin using the runtime we set the InstallPath to where the shared installation is.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

MarkCederholm — Fri, 22 Oct 2021 17:22:27 GMT

I am definitely interested this topic, and one other, related to .NET 5 migration, if anyone can point me in the right direction. Microsoft doc searches keep pointing me back to the old Framework.

Is there a simple way, not hacking into JSON configs, to point Runtime to a particular shared deployment path?
Is there a way to tell assembly probing NOT to look for .resource dlls when using Assembly.LoadFrom and Assembly.CreateInstance?

My gratitude always,

--Mark

Update: I think I finally found what I'm looking for:

https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

MarkCederholm — Fri, 22 Oct 2021 17:20:32 GMT

Replacing Assembly.LoadFrom with AssemblyLoadContext.Default.LoadFromAssemblyPath cleared up the resource DLL problem. Now I'll look into the possibility of using the native dll search options to point to a shared Runtime deployment.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

TroyAvery1 — Fri, 22 Oct 2021 17:28:31 GMT

Nice to know. The effort I originally discovered this under was for a migration to another project. We had the ESRI Runtime access contained in a library so it could be swapped out if needed. This had it deployed as a shared resource. The new project didn't see the need to use a shared library so it was integrated into the project which then removed the need to specify the "InstallPath" hence why I did not pursue the issue any farther.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

dotMorten_esri — Fri, 22 Oct 2021 17:35:02 GMT

Here's the gist of how to hint .NET Core where to look for native libraries to load:

private static IntPtr runtimeLibPtr = IntPtr.Zero; private static IntPtr runtimeLibWpfPtr = IntPtr.Zero; private const string version = "100_13"; private const string InstallPath = @"C:\ArcGISRuntimeInstall\"; private static IntPtr DllImportResolver(string libraryName, System.Reflection.Assembly assembly, System.Runtime.InteropServices.DllImportSearchPath? searchPath) { string path = $"{InstallPath}x{(Environment.Is64BitProcess ? "64" : "86")}\\{libraryName}"; if (libraryName == "RuntimeCoreNet" + version + ".dll" && assembly.FullName == typeof(Esri.ArcGISRuntime.ArcGISRuntimeEnvironment).Assembly.FullName) { if (runtimeLibPtr == IntPtr.Zero) { if (System.Runtime.InteropServices.NativeLibrary.TryLoad(@$"{path}", out runtimeLibPtr)) return runtimeLibPtr; } return runtimeLibPtr; } else if (libraryName == "RuntimeCoreNet" + version + ".WPF.dll" && assembly.FullName == typeof(Esri.ArcGISRuntime.UI.Controls.MapView).Assembly.FullName) { if (runtimeLibWpfPtr == IntPtr.Zero) { if (System.Runtime.InteropServices.NativeLibrary.TryLoad(@$"{path}", out runtimeLibPtr)) return runtimeLibWpfPtr; } return runtimeLibWpfPtr; } return IntPtr.Zero; }

You would then hook this Dll import resolver up at app startup before calling into any of our APIs:

System.Runtime.InteropServices.NativeLibrary.SetDllImportResolver(typeof(Esri.ArcGISRuntime.ArcGISRuntimeEnvironment).Assembly, new System.Runtime.InteropServices.DllImportResolver(DllImportResolver)); System.Runtime.InteropServices.NativeLibrary.SetDllImportResolver(typeof(Esri.ArcGISRuntime.UI.Controls.MapView).Assembly, new System.Runtime.InteropServices.DllImportResolver(DllImportResolver));

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

MarkCederholm — Fri, 22 Oct 2021 23:07:23 GMT

I've run into two issues:

Shared resources are still expected to reside in the application folder
I'm getting the following error:
Unable to find an entry point named 'CoreRT_GeoView_setScreenScale' in DLL 'RuntimeCoreNet100_12.dll'.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

MarkCederholm — Tue, 26 Oct 2021 01:39:16 GMT

To clarify, I set up what I thought was a simple test, but if I made a glaring error another set of eyes always helps. I created a deployment which looks like this:

And here's the code for App.xaml.cs:

using Esri.ArcGISRuntime; using System; using System.Collections.Generic; using System.Configuration; using System.Data; using System.IO; using System.Linq; using System.Reflection; using System.Runtime.InteropServices; using System.Runtime.Loader; using System.Threading.Tasks; using System.Windows; namespace DeploymentTest { /// <summary> /// Interaction logic for App.xaml /// </summary> public partial class App : Application { private static IntPtr runtimeLibPtr = IntPtr.Zero; private static IntPtr runtimeLibWpfPtr = IntPtr.Zero; private const string DeploymentHome = @"C:\apps"; private const string RuntimeVersion = "100.12"; private static string NativeInstallPath; private static string DLLversion; private void Application_Startup(object sender, StartupEventArgs e) { try { string sRuntimeDeployment = "ArcGISRuntimeCore" + RuntimeVersion; string sInstallPath = Path.Combine(DeploymentHome, sRuntimeDeployment); if (Directory.Exists(sInstallPath)) { NativeInstallPath = Path.Combine(sInstallPath, "runtimes"); DLLversion = RuntimeVersion.Replace('.', '_'); NativeLibrary.SetDllImportResolver(typeof(ArcGISRuntimeEnvironment).Assembly, new DllImportResolver(DllImportResolver)); NativeLibrary.SetDllImportResolver(typeof(Esri.ArcGISRuntime.UI.Controls.MapView).Assembly, new DllImportResolver(DllImportResolver)); string sAssemblyPath = Path.Combine(sInstallPath, "Esri.ArcGISRuntime.dll"); AssemblyLoadContext.Default.LoadFromAssemblyPath(sAssemblyPath); sAssemblyPath = Path.Combine(sInstallPath, "Esri.ArcGISRuntime.WPF.dll"); AssemblyLoadContext.Default.LoadFromAssemblyPath(sAssemblyPath); } // Initialize the ArcGIS Runtime before any components are created. ArcGISRuntimeEnvironment.Initialize(); } catch (Exception ex) { MessageBox.Show(ex.ToString(), "ArcGIS Runtime initialization failed."); // Exit application this.Shutdown(); } } private static IntPtr DllImportResolver(string libraryName, System.Reflection.Assembly assembly, System.Runtime.InteropServices.DllImportSearchPath? searchPath) { string path = $"{NativeInstallPath}\\win-x{(Environment.Is64BitProcess ? "64" : "86")}\\native\\{libraryName}"; if (libraryName == "RuntimeCoreNet" + DLLversion + ".dll") // && assembly.FullName == typeof(Esri.ArcGISRuntime.ArcGISRuntimeEnvironment).Assembly.FullName) { if (runtimeLibPtr == IntPtr.Zero) { if (NativeLibrary.TryLoad(@$"{path}", out runtimeLibPtr)) return runtimeLibPtr; } return runtimeLibPtr; } else if (libraryName == "RuntimeCoreNet" + DLLversion + ".WPF.dll") // && assembly.FullName == typeof(Esri.ArcGISRuntime.UI.Controls.MapView).Assembly.FullName) { if (runtimeLibWpfPtr == IntPtr.Zero) { if (NativeLibrary.TryLoad(@$"{path}", out runtimeLibPtr)) return runtimeLibWpfPtr; } return runtimeLibWpfPtr; } return IntPtr.Zero; } } }

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

TroyAvery1 — Tue, 26 Oct 2021 15:51:27 GMT

I don't do a lot of dynamic DLL loading, but the times I have done so, have shown me that any reference to the type before the load is complete is catastrophic.

As such, would not lines 39, 40 cause problems as they attempt to get a Type reference from a type before the library load is performed/finished?

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

MarkCederholm — Tue, 26 Oct 2021 19:50:17 GMT

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

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

TroyAvery1 — Tue, 26 Oct 2021 21:21:18 GMT

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.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

dotMorten_esri — Wed, 27 Oct 2021 17:03:25 GMT

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.ArcGISRuntimeEnvironment.InstallPath.html )

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

dotMorten_esri — Wed, 27 Oct 2021 17:11:17 GMT

@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.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

TroyAvery1 — Wed, 27 Oct 2021 17:19:52 GMT

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();
}

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

JeremyBridges — Thu, 04 May 2023 20:58:09 GMT

Unfortunately, we're not able to use the SetDllImportResolver method when unit testing in VS 2022. Perhaps this methodology is different in that situation? Our main question is what is in this central runtime folder ("C:\ArcGISRuntimeInstall\"). Should it be filled with the contents of the nuget package? If so, which part of it? Attached is our guess of what those files are.

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

TroyAvery1 — Thu, 04 May 2023 22:01:33 GMT

Can’t see the doc, our company has things locked up tighter than the CIAs plans for the Kennedy assassination.

If memory is correct this example was a WinForms migration to WPF attempt that was being done for a more up to date project. In the end, this project elected to just import it directly as they were not interested in sharing a deployment.

The traditional WinForms version of this contained the ESRI nugget package content.

.\Esri.ArcGISRuntime.dll

.\Esri.ArcGISRuntime.xml

.\arcgisruntime100.X\client32 (and all files in subdirs)

.\arcgisruntime100.X\client64 (and all files in subdirs)

.\arcgisruntime100.X\resources (and all files in subdirs)

This ran for some time just without the client32 folder as we had a 64 bit, but it was added for the purpose of completeness. This is still in use today shared among a collection of WinForms applications.

I expect you are working a WPF solution and I believe the content is different but the idea is the same. I don’t know if you can trim it down the same way in that environment, but there’s no big loss just including everything. Though I do wish there was a way to safely ditch the language packs we know we won’t use (or maybe there is I never got around to trying it).

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

SomeGISGuy — Thu, 04 May 2023 22:09:06 GMT

> Our main question is what is in this central runtime folder

There is no central runtime folder. When you compile your application, everything the application needs (apart from .NET itself) will be copied to the output folder. What those folders are depends on your build configuration, processor architecture and target framework.

We run unit tests daily with the runtime nuget packages, and the deployment that is generated works "as is" with both test explorer and commandline vstest.console. What issue are you hitting?

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

SomeGISGuy — Thu, 04 May 2023 22:12:41 GMT

> I do wish there was a way to safely ditch the language packs we know we won’t use

Re: Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

JeremyBridges — Thu, 04 May 2023 22:42:28 GMT

It's pretty particular. We have a Xamarin.Forms project where we needed to bump forward to net6.0 on the iOS and Android projects for some newer dependencies. This required that we bump the shared .NET Standard library (that contains our XAML and all the core app logic) to netstandard2.1. The unit test projects couldn't target net48 anymore because of this change. We are trying net6.0-windows10.0.18362.0 for those unit test projects, but cannot make the Runtime happy. Gives the typical error:

System.DllNotFoundException : Unable to load DLL 'RuntimeCoreNet100_15_1.dll'