Invalid ArcGISRuntime deployment, unable to load native dll

7883
14
12-05-2016 03:04 AM
AaronMurphy3
New Contributor III

I'm trying to create a test project to help me migrate from 10.2.7 to 100.0.0, I am getting the following exception when all I have is a MapView with a name.

Additional information: Invalid ArcGISRuntime deployment, unable to load native dll. Maybe a missing native dependency, checking with dependency walker may help resolve this issue. C:\Users\aaron.murphy\Documents\Visual Studio 2013\Projects\WpfApplication1\WpfApplication1\bin\Release\arcgisruntime100.0\client32\RuntimeCoreNet.dll

The dll exists, what's the issue guys?

14 Replies
AaronMurphy3
New Contributor III

Error 1 Error initializing ArcGISRuntimeEnvironment. Unable to find ArcGISRuntime deployment folder. To create a deployment run the ArcGISRuntime Deployment Tool to create a folder called arcgisruntime100.0. Place this in the same folder as your exe, or set the ArcGISRuntimeEnvironment.InstallPath to point to a different location. This deployment folder must contain sub-folders matching your process architecture. For developers you can also install the ArcGIS Runtime .Net SDK, which includes a deployment folder. C:\Users\aaron.murphy\Documents\Visual Studio 2013\Projects\WpfApplication1\WpfApplication1\MainWindow.xaml

I have this aswell, I can clearly see what it's saying but the folder exists!

0 Kudos
RichZwaap
Occasional Contributor III

Hi Aaron,

Are you seeing this error when you run the application?  Or just in Visual Studio when you have the XAML page open?  If the error is occurring when viewing the XAML, then something's gone wrong with locating the assembly at design-time, in which case it won't affect the functionality of the application when executing.

-Rich

0 Kudos
AaronMurphy3
New Contributor III

Hi Rich,

Currently, the MapView control has a squiggly line underneath and when I try to build I get the following exception:

A first chance exception of type 'System.Windows.Markup.XamlParseException' occurred in PresentationFramework.dll

Additional information: The invocation of the constructor on type 'Esri.ArcGISRuntime.UI.Controls.MapView' that matches the specified binding constraints threw an exception.

And during design time it has an error that says:

Unable to load DLL 'RuntimeCoreNet.dll':The specified procedure could not be found. (Exception from HRESULT: 0x8007007F)

0 Kudos
ChristopherMoravec2
New Contributor III

I have this error as well, below is what I have done to try to get it working.  

I first got it in my unit tests.  I was able to fix that by adding the following code to my test class:

[TestInitialize]
public void ConfigureArcGIS()
    {
        if (!Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.IsInitialized)
            Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.InstallPath = Directory.GetCurrentDirectory();
    }‍‍‍‍‍‍‍

I am also getting this in my click-once deployment.  The Release/Debug folder in "bin" always has the ArcGISRuntime100.0 folder, but when I made the click-once deployment it never had that folder.  I was able to get around that by copying that folder into a sub folder in my Project, and editing my .csproj file to have the following in it (At the beginning, and this is not the full file):

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="include.csproj" />

And then creating the include.csproj to have this content (The ArcGISRuntimeInclude folder is at the root of my project, and contains the ArcGISRuntime100.0 folder from the "Release" folder):

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Content Include="ArcGISRuntimeInclude\**\*.*">
  <Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
  <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
</Project>

That ensures that the files are included in my deployment, but when I install, I am still getting an error:

Application: RiskViewer.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException
   at RuntimeCoreNet.GeneratedWrappers.CoreArcGISRuntimeEnvironment.CoreRT_ArcGISRuntimeEnvironment_setInstallDirectory(Byte[], IntPtr ByRef)
   at RuntimeCoreNet.GeneratedWrappers.CoreArcGISRuntimeEnvironment.SetInstallDirectory(System.String)
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.TryInitialize()

Exception Info: System.InvalidOperationException
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.TryInitialize()
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.InitNative()
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.Initialize()
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.SetLicense(System.String)
   at RiskViewer.App..ctor()
   at RiskViewer.App.Main()

I have also tried forcing the directory to be set in my App.xaml.cs, and I get the same error as above.  Still working on it though...

My App.xaml.cs:

public App() : base()
        {

            if (!Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.IsInitialized)
                Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.InstallPath = Directory.GetCurrentDirectory();


            string licenseKey = "<license key here>";
            Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.SetLicense(licenseKey);

           
        }

I'll post back if I get it to work.

Christopher

0 Kudos
RichZwaap
Occasional Contributor III

Hi Christopher,

The behavior you describe is essentially as expected.  When building an app project, there are build events that will copy the Runtime deployment directory into the project's output directory.  But when it comes to deploying an application, it's up to the developer to either see to it that the deployment directory is deployed along-side the executable, or, if it is preferable to deploy it to another location, then the InstallPath property must be set.

Hope this helps.

-Rich

0 Kudos
ChristopherMoravec2
New Contributor III

Rich,

Thanks for the reply, I guess I was just a little confused about how it worked, the docs (Deploy your app—ArcGIS Runtime SDK for .NET | ArcGIS for Developers ) seemed to me to indicate that the ArcGISRuntime100.0 folder would be included in the deployment.  It is, in a way; it is created in the bin/Release folder correctly, but it is not included "Application Files" within the Publish tab on the project properties (All of the language resources and the root Esri.ArcGISRuntime.dll are).  So I had to go through some extra work to get those files to be included in the publish.

Anyway, now that they are in the publish, the app still gives that error when I run it on a different computer.  The ArcGISRuntime100.0 folder is there, and is exactly the same as it is in the "Release."  I have even copied the entire "Release" folder to a fresh machine and tried to run my app, but I get the same error each time.

If I put a try/catch around the SetLicense call I get this:

With this in the event viewer:

Application: RiskViewer.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException
   at RuntimeCoreNet.GeneratedWrappers.CoreArcGISRuntimeEnvironment.CoreRT_ArcGISRuntimeEnvironment_setInstallDirectory(Byte[], IntPtr ByRef)
   at RuntimeCoreNet.GeneratedWrappers.CoreArcGISRuntimeEnvironment.SetInstallDirectory(System.String)
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.TryInitialize()

Exception Info: System.InvalidOperationException
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.TryInitialize()
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.InitNative()
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.Initialize()
   at Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.SetLicense(System.String)
   at RiskViewer.App..ctor()
   at RiskViewer.App.Main()

So, I downloaded decency walker (which is kinda old) and found that it could not load this (and related): API-MS-WIN-CORE-WINRT-L1-1-0.DLL

But, from previous experience I know that dependency walker sometimes messes up when it comes to this DLL, so I used Process Monitor, and filtered it for my app and found that it does in-fact find the RuntimeCoreNet.dll:

However, as I continued to scroll through the results, I found that it does not find MSVCP140.dll:

So, the machine is missing the VC++ Redistributable.  I didn't remember needing that when I tested this in the beta, so I checked, and my test deployment from the beta had the following extra DLLs: concrt140.dll, msvcp140.dll, vcccorlib140.dll, and vcruntime140.dll

I'm not sure if those used to be included in the deployment in the Beta or, if I added them (I don't remember).  But adding those four files fixed my issue.

I'm not sure if this is important at this point but, it does not matter if I select "Any CPU," "x86," or "x64" I only get the client32 folder, I never get a client64 folder.  I used to get a client64 folder in the beta, but now no matter what I do, I don't get one.

0 Kudos
RichZwaap
Occasional Contributor III

As you found, the VC++ Redistributable is indeed a pre-requisite for WPF Runtime apps.  This is documented under the "Requirements for deployment targets" section of the System requirements topic.

The client64 folder ought to be getting copied to the output folder if the app project is targeting x64.  That would be unexpected if that's not the case.

-Rich

0 Kudos
ChristopherMoravec2
New Contributor III

Rich,

If I could ask, it would help me a lot if the system requirements were linked from the deployment page, I tend to forget stuff!

As for the client64 folder, I'm not sure if I have messed something up here, but if I remove all of my changes to the csproj file and try to run my app in Debug x64 from VS, it loads and runs correctly, but there is only a client32 folder created, no client64.  Same if I run it on x32 or AnyCPU.  Any suggestions?

Thanks,

Christopher

0 Kudos
RichZwaap
Occasional Contributor III

Any suggestions?

On the Build tab of the project properties, make sure that the Platform target reflects what you'd expect.  I just gave this a quick test with the various values (x64, x86, and Any CPU with and without Prefer 32-bit checked), and the client32/64 folders are being copied to output as expected.

0 Kudos