Deployment problems with C++ sdk for 100.2 runtime windows using msvc2017_64

[ChristianNuckols]

I'm having trouble deploying software from my  PC (on which I am developing our app) to our tablets (which are identical to our clients' systems).  Both use windows and the msvc compilers are up to date on both of the systems.  I know the tablets meet the system requirements for the runtime, because I've been able to build and deploy sample apps.    For instance, on the tablets, I can build and deploy the basic 'Display Map' sample if I comment out

import Esri.ArcGIS Extras 1.1

but if I don't, the app loads, but nothing is rendered:

I understand that the extras require more .dll files.  I'm able to deploy apps with the Extras component (to any location on disk) on the development PC even if I explicitly set the runtime environment variable:

ArcGISRuntimeEnvironment::setInstallDirectory(QDir::currentPath());

I should note, that I am not actually using the extras component in my app.  Deployment of the sample apps was part of my  attempt to diagnose the issue, and I came across that problem.   To deploy my app on the development PC, I take the following steps:

1. Compile my release in QtCreator.  This stores the executable here:

C:\Users\cnuckols\ArcGIS\AppStudio\Apps\build-ULIP-Desktop_Qt_5_10_0_MSVC2017_64bit-Release

And the storage folder for my source code is:

C:\Users\cnuckols\ArcGIS\AppStudio\Apps\ULIP\

2. Move the executable to a folder on my desktop:

C:\Users\cnuckols\Desktop\Deployment2\ULIP.exe

3. Use the qt deployment tool for windows:

I should note that I've tried this with and without the angle option.

4. Copy the sdk runtime .dlls to the deployment folder:

Here are the contents of my deployment folder:

5. I run the app, and it works correctly.  However, when I move the deployment2 folder to the tablet it executes, but nothing is rendered:

I get no error messages and no warnings.

To further clarify, when I look at which dlls are being used by ULIP.exe in the tablet,  msvcp140.dll and vcruntime140.dll. are both listed (the ones contained in System32):

C:\WINDOWS\SYSTEM32\MSVCP140.dll

and

C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll

-I have read the page on deploying the app:

Deploy your app—ArcGIS Runtime SDK for Qt | ArcGIS for Developers 

-I have read the system requirements page for the newer runtime:

System requirements for 100.3.0—ArcGIS Runtime SDK for Qt | ArcGIS for Developers 

-I have read every geonet thread on deployment issues for the Qt SDK

-I am using the QtQuick Compiler

-I've been using the Qt windows deployment tool and have read the Qt page about using the tool:

Qt for Windows - Deployment | Qt 5.11 

Thanks!

[MichaelTims]

and either append a version number to ArcGIS Extras to the copied subfolder or copy the appropriate Extras import library from the corresponding sample sdk

This shouldn't be required.  I am able to have the folder named as "qml\Esri\ArcGISExtras" without the ".1.1" on the end and it works fine to detect the import.

Even if your app doesn't use this import. My app doesn't and this was the difference between it functioning on the deploy device or not.

This should not be the case either.  The "qml\Esri\ArcGISExtras" does not need to come along in the deployment of the app unless there is a QML file somewhere which imports "import Esri.ArcGIS Extras 1.1"

Thanks.

-Michael

[ChristianNuckols]

What you're saying makes sense; the qml import should not need to be named to correspond the version (or included) if it isn't used at all. I don't have a diagnosis for why adding the version number fixed my problem, all I know is that I'm sure I tried an identical deployment without the version number appended to the folder and the deployment didn't function. I have quite a few QML components that imported the parent qml class(component?) which many builds ago *did* have the import statement, so one guess is that maybe some part of the makefile wasn't getting updated correctly and was still looking for the import?  Which still doesn't explain why the version number itself would be necessary.  In any case, after I got the issue resolved I added the Extras import again to use the scaleFactor property.  If I have time to figure out what the problem was I'll definitely come back to this thread and explain what was happening.  But you're right, it shouldn't behave in that way.