topic Deployment problems with C++ sdk for 100.2 runtime windows using msvc2017_64 in Qt Maps SDK Questions

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

ChristianNuckols — Fri, 27 Jul 2018 15:58:58 GMT

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!

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

JamesBallard1 — Fri, 27 Jul 2018 17:46:27 GMT

Hi Christian Nuckols.

Thanks for the excellent troubleshooting. Can you see if the Extras folder is included in your deployment? It should be in the qml folder, like follows. It may be named just "ArcGISExtras", too. Please take a look.

That's the expected location for the Extras deployment.

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

ChristianNuckols — Fri, 27 Jul 2018 18:01:58 GMT

No I can't. Should I be seeing a qml folder even if I'm using the QtQuick compiler?

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

ChristianNuckols — Fri, 27 Jul 2018 18:04:45 GMT

I should also note that I have this folder in my ArcGIS SDKs directory:

C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\windows\x64\qml\Esri\ArcGISExtras

which has the same file structure, but doesn't use the version number.

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

JamesBallard1 — Fri, 27 Jul 2018 18:09:58 GMT

You'll still need the qml folder in a deployed app, even with the QtQuick Compiler. You can grab that entire "C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\windows\x64\qml" folder and drop it into your deployment (the whole qml folder). Please let me know if that helps.

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

JamesBallard1 — Fri, 27 Jul 2018 18:14:11 GMT

Christian Nuckols‌ a good example of a deployed Windows app is included with the setup. See "C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\samples\ArcGISRuntimeSDKQt_QMLSamples\bin". The "qml" folder structure should be similar to what you need for your deployed app.

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

ChristianNuckols — Fri, 27 Jul 2018 18:40:04 GMT

Thank you. I tried adding the just the QML folder you linked to and got the same result.

C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\windows\x64\qml

The extras folder doesn't have version info, which was different from the qml folder in the esri samples:

C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\windows\x64\qml\Esri\ArcGISExtras

C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\samples\ArcGISRuntimeSDKQt_QMLSamples\bin\qml\Esri\ArcGISExtras.1.1

Also, should I be using the ArcGISRuntimeSDKQt_QMLSamples or ArcGISRuntimeSDKQt_CppSamples as a reference? (im using QML and cpp - have multiple .qml and multiple .cpp files)

Also I tried moving all of the api-ms-win*.dll files to my app, in addition to copying any missing files. (from both the QML samples and the cpp samples). In both cases, I got this as a result:

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

ChristianNuckols — Fri, 27 Jul 2018 18:53:50 GMT

James, I got the app to deploy by appending the version number. Thanks so much for your help!

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

JamesBallard1 — Fri, 27 Jul 2018 18:56:03 GMT

Christian Nuckols‌, that's great news! Happy to help.

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

ChristianNuckols — Fri, 27 Jul 2018 19:02:35 GMT

For anyone coming across this thread, when you copy this folder into your deployment:

C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\windows\x64\qml

you need to look at

C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\windows\x64\qml\Esri\ArcGISExtras

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

C:\Program Files (x86)\ArcGIS SDKs\Qt100.2.1\sdk\samples\ArcGISRuntimeSDKQt_CppSamples\bin\qml\Esri\ArcGISExtras.1.1

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.

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

MichaelTims — Fri, 27 Jul 2018 22:33:31 GMT

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

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

ChristianNuckols — Mon, 30 Jul 2018 14:43:52 GMT

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.