I am new to Qt, and I am working in Windows 7.
When I try to run my application directly, I see an error about missing some DLLs. I tried to fix them, but I could not (I tried to build statically).
Is there any correct solution?
My question is:
If I want to run my Qt application on other computers, what do I need? For example, for a .NET application we need to install the .NET framework on the target computer, but what about for Qt?
I searched for its SDK and found a SDK that was about 1.6 GB! Does this mean every time I want to install my application I should install a 1.6 GB sized SDK? That's far too bad.
Thanks.
You have to distribute your application with needed libraries.
If your application is running on Windows you can follow this guide: Deploying an Application on Windows. You can find needed libraries as dll in bin directory inside SDK. A basic Qt gui application needs at least QTCORE4.DLL, QTGUI4.DLL and, if you are using Qt Creator, MINGWM10.DLL. You can leave these libraries in the same directory as you application.
You can't link statically against Qt unless you have built the libraries in that configuration (which you won't if you've just downloaded the pre-built SDK). Be aware that if you do want to link statically there are licensing implications for some components.
If you have built a release configuration then you will need at least the libraries Alessandro mentioned, QtCore4.dll and QtGui4.dll. Depending on the other parts of the library you're using you may also need QtXml4.dll QtWebkit4.dll, QtXmlPatterns4.dll and possibly Phonon.dll. Check that you are building a release configuration rather than a debug configuration, as this won't run as it needs the Visual Studio debug runtimes, which you can't redistribute. If you are in doubt which dlls you need then use DependencyWalker to find out (note that this doesn't show Phonon.dll as it is loaded later).
Generally you'll only need about 4-6 of the dlls, you won't need the whole SDK.
Please consider that many applications use Qt, you have some real chance the DLLs are already installed. Anyway, beware of MSVC dependencies: we had some real nightmare deploying applications on some server, partly related to a policy switch from VS2005 to VS2008. Alessandro already given a good resource: see also this previous post.
If you're working with Qt5, besides the .dlls mentioned by the first answer, you must also add the platforms/ folder from the bin directory inside the SDK.
Related
I'm trying to add a full framework class library as a project reference to asp.net core 2.0 MVC project and getting the below error.
Project XYZ is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0).
Project XYZ supports: net462 (.NETFramework,Version=v4.6.2)
I have updated to the most recent version of Visual studio i.e, 15.3.5.
Is it even possible to reference 4.6.2 libraries in core 2.0 projects?
The first thing that you can try is to compile the library you want to consume as netstandard2.0.
Theoretically (according to the .net standard documentation), this will make it compatible with projects using net461 and later as well as netcoreapp2.0 and later.
In practice, sometimes you will end up with a problem with one of your dependencies that don't provide the same library version across different compilation targets.
In such cases you may simply need to add the .net core 2.0 as a target framework for the XYZ library.
The xml tag listing the targets is <TargetFrameworks> in the XYZ.csproj file and is not handled by the Gui of the project's properties.
So I would give a try at editing the XYZ.csproj by hand and add or replace what's listed as <TargetFrameworks> with netcoreapp2.0.
If you are adding it as additional target you need to separate them with ';' as in
<TargetFrameworks>net462;netstandard2.0;netcoreapp2.0</TargetFrameworks>
More details about this in this Microsoft doc.
Please keep in mind that this will trigger multiple compilations and will slow your build consequently...
It should be. Microsoft announced a ".NET Framework Compatibility Mode" with the release of .NET Standard 2.0. However, they didn't go into great detail about how it works exactly, or what to troubleshoot if it doesn't. Additionally, they only specific talk about it in relationship to Nuget packages, so it's possible there's some role Nuget is playing in the process, as well. Unfortunately, I've been unable to find any additional information about this feature outside of the announcement post.
That said, Microsoft's explicit recommendation is to not rely on the fact that your .NET Framework library may just happen to work in .NET Core; instead, you should be actively porting .NET Framework libraries you control to .NET Standard. I'd say you're likely going to spend more time trying to figure out why it doesn't "just work" than you would porting your code, so that it will definitely work, and be future-proof to boot.
The following solution worked for me.
Deleted bin and obj folders from all the projects in the solution, rebuild and if it still doesn't work try changing browser from debug options. for eg. If you already have chrome as default browser in Visual studio, switch to Edge or Firefox.
Am I doing this right? I've got many, many separate ASP.NET webforms projects which reference the same main library which contains many tool methods. When I change something in that library, I don't know of a way to make sure that these projects get the updated version of the library. Does auto-refresh detect changes in references even if you don't open the project in Visual Studio? Or does IIS know when a reference has changed and will recompile the project?
Assuming the DLL file is binary compatible (changing an existing method signature is the easiest way to break compatibility) all it comes down is that the newest DLL is in the \bin\ folder. If the site is running it would need to be restarted to pick up the DLL being replaced.
If this is a project reference in your solution, building just does all of this for you.
If this project is outside of your solution, you really should look into using Nuget to distribute this shared project. Even if you only distribute it to yourself. You do not need to host the package publicly on nuget.org
Jpegs are fine on my developer machine, but are not supported when i deploy my application to a fresh machine. all jpeg files used in stylesheets are still built with the application's resources, but are never displayed.
I tried deploying an "imageformats" folder, child of the executable folder, containing a "qjpeg4.dll" inside.
I tried linking against the qjpeg4.lib in my .pro file, WITH what's specified above.
still no good. Is there something in code I need to specify?
You need to deploy qt plugins with your application. Deploying Qt apps on Windows
This is just a guess, but I'm wondering if there is some dependency of the plugin that cannot be resolved on the virtual machine. Like you said, it is a simple file/folder thing, so it is probably finding the plugin dll. But maybe the dll is failing to load because it cannot resolve one if its dependencies.
The most likely culprit would be the C++ runtimes. Are you deploying those side-by-side in the application directory, or installed via the redistributable? If the former, the plugin may not be able to find them since it is in a different directory. To track this down, you could use the "Dependency Walker" and "SxSTrace.exe" tools.
I just have a little question about running Qt created apps on different operating systems.
As a normal user do i have to install Qt framework to run Qt apps ?
I mean i've created Qt app using Windows , then i made a build for Linux .
Do i need to install the Qt framework on the Linux pc inorder to run that app ?
Or there is a way to package all the needed libraries into the app installer .
Best Regards
You can deliver the dynamic libs you need with your application, as it's described here:
http://doc.qt.io/qt-5/deployment.html
Since Qt is not a system library, it has to be redistributed along
with your application; the minimum is to redistribute the run-time of
the libraries used by the application. Using static linking, however,
the Qt run-time is compiled into the executable.
Depends what you mean by 'framework', you will need the runtime libraries, unless you paid Nokia for a license to allow static linking.
For Linux, I think you would generally ensure that the Qt packages have been installed during installation (i.e. make them a requirement of the package you provide). Under Mac OS you would need to package the .so (shared objects) with your application. Under Windows you do the same (provide the .dlls) and install them with the application (not in the system folders).
The issue with static linking that #cbamber85 is alluding to, is the conformance with the LGPL licence where it's legal to link to the libraries at runtime but not at compile time (i.e. use the .so/.dll but not the .a files).
In Qt when I build a project it creates the executable but it doesn't include the necessary DLLs. Is their some option I can turn on to do this for me?
I'll assume you are referring to deploying your application. If you build with static linking to Qt, you won't have to distribute Qt DLLs but you will have a large executable. You may have to compile the Qt library yourself to get static libraries.
Dynamic linking will require you to copy the appropriate Qt DLLs with your application. Some build environments may have an option to help with this. If you mention what your development tool chain and platform is in the question, somebody may be able to help with specifics.
Qt has some documentation related to deployment here.