@JDePedro
Ok. I found the cause why I was not getting anything QML related from the tool. My widget is not in the exe file but in a DLL so I had to specify the dll instead.

But the list of files the tool is getting is huge compared with the one I got by doing the process "manually" and includes most of the .qml files. So my doubt is, do we need to deploy all this files with my application? is not enough with the dlls???

Ok i found the problem i just forgot to put the config file in my Deployment folder.
Thanks for the help @jsulm .

Hello,

Sorry, it took me a bit of time to make the tests:

A simple "Hello world" project runs correctly in Qt Creator? When using the external lib, the program crashes. I suspect an incompatibility of this old lib with Windows 10.
I need to further investigated this issue...

Many thanks for your help!

No, as suggested in my previous post, you have to deploy the Qt Multimedia plugins.

Did you use windeployqt to prepare your application for deployment ?

Are you sure you ran the correct version of windeployqt ? If you use the tool from the mingw folder for an app that was compiled with MSVC you'll end up with the wrong files and libaries inside your deploy directory.

@aha_1980 Thank you for exact answer. I am able to call the script with help of Qt creator Project settings.

Does the app work if you start it with --single-process added to the command line?

Perhaps some dll files are missing.

@jsulm said in Qt creator cannot successfully start app built with custom built qt bundle on windows:

@farta clone means here cloning from Qt repository (git clone)

Thank you.
I never clone it from Qt repository.

Hi,

Use the amd64 command prompt when building Qt.

@SGaist thanks!

@kshegunov said in qmake install error detection on Windows:

target.depends = baseLibs

This was a very promising idea but unfortunately it looks like .depends does not work with other INSTALLS tagets

@mounipanditi

According to the Screens every thing is fine, but make sure that SFTP server is running in the target device so that application can be deployed into the target device.

@hskoglund said in Crushes after deploying!:

Hi, googling finds many with the same problem, for example here
Just guessing, but perhaps you could try some of the suggestions in there...

Thanks for the link.
It seems this issue doesn't even solved in Stack Overflow :(

Any way, I did some of the suggestions mentioned in it.

Installed all redistributable package of x86 (cuz I built my app using Qt mingw53_32) for 2012 - 2013 - 2015 - 2017 (I tested my app after each vcredist) Installed all redistributable package of x64 for 2012 - 2013 - 2015 - 2017 (I tested my app after each vcredist)

Nothing changed still see my app crashes without any logical reason!

Now I'm very sad because I can run my app only if I installed Qt on my machine which is impractical solution for deploying my app.

@Rafo If you only provide binaries, why don't you provide needed Qt libraries together with your app? This is what is usually done. This way you make sure your app is always using libs it was linked against.

Thanks @mrjj .
The Problem was the Quazip that was linking to dynamic Qt libs witch Dependency walker won't show up at run time.

First i should build it as static like so :

TEMPLATE = lib CONFIG += qt warn_on QT -= gui DEFINES += QUAZIP_BUILD CONFIG += staticlib CONFIG(staticlib): DEFINES += QUAZIP_STATIC include(quazip.pri)

Then i should link that in my .pro :

. . . LIBS += -L$$PWD/quazip/ -lquazip INCLUDEPATH += $$PWD/quazip PRE_TARGETDEPS += $$PWD/quazip/quazip.lib DEFINES += QUAZIP_STATIC . . .

@hskoglund said in How to correctly deploy a modular Qt-Application on windows? (Contains: can not display svg-files in qml):

You could check the list of directories from where Qt tries to load its plugins by calling QCoreApplication::libraryPaths()

That looks like a cunning plan :) <insert Blackadder reference here>

I played around with this information a bit and made the following observations:

Dumping the library paths in the constructor of my module indeed lists only the module directory, but not the application directory. So I guess you mean the relative path when you say

Your module_ui.dll inherits the search path from the .exe for .dlls

Adding the application folder to the library search path within the module constructor solves the issue without the need for double-deployment

Thanks a lot, you brought me on the right track.