Esri.ArcGISRuntime.ArcGISRuntimEnvironment.InstallPath

[TroyAvery1]

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.

[MarkCederholm]

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

[TroyAvery1]

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.

[dotMorten_esri]

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

[TroyAvery1]

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

[JeremyBridges]

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.

[TroyAvery1]

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

[dotMorten]

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

<PropertyGroup>
  <SatelliteResourceLanguages>en;es;de</SatelliteResourceLanguages>
</PropertyGroup>

[dotMorten]

>  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?

[JeremyBridges]

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'

[JeremyBridges]

bin directory of the unit test project seems to have everything it needs in its runtimes directory (see first two attachments). Though, this is on a Mac, running Windows 11 ARM through Parallels. So, perhaps the test runner in VS 2022 Preview (which is compiled for ARM) is trying to run the tests under ARM64... That runtimes directory is rather empty (see third attachment).