I have got a strange problem with my deployment of an Qt application. I created a Zip with all the necessary dlls and my binary on my Windows XP 32 bit box, where the application worked just fine,
Then I tested this on my laptop running windows 7 64 bit, giving me strange results. The window icons are back to the default ones and my system tray icon is invisible. Everything else is working.
As I paint a logo from the same resource file on the window (and this works on both machines) the resource file should be loading fine.
I then copied the dlls (that I installed with the same installer) from my win7 machine to the directory of my binary and the icons work again. I checked the dlls hash and they are identical.
Also I tried these dlls on my XP machine, and this time it does not show the icons.
This is quite strange because the dlls are installed from the same package and are identical, but are not working on the other machine.
Is there anything I have overlooked?
I am using QT 4.7 and the msvs2008 installer plus addin.
If you deploy the plugins to your application directory you have to use the directories imageformats and iconengines (without the plugin/ prefix).
See the Documentation about Deploying Plugins
Edit: And if you use QML, you also have to copy the content of the "imports" directory (also without the imports/ prefix) to your application directory.
Related
Coming from Linux, using QT5.4 (app compiles and works as expected)
If you are interested in the topic, just get fancybrowser example running on a XP machine without QT installed...
My first attempt was using MXE (and manually copying dlls). No success.
set up VM with Windows XP.
using windeployqt.
app "works" but QWebView doesn't display anything.
trying qt.conf
[Paths]
Prefix=.
and more things.
Still not successful.
windeployqt with all options to include webkit, compiler, angle...
No success...
Reading about QWebEngine will be the next.
Compiling a small example on Linux(OK) Windows (Mingw does not support qwebengine!!!).
So before setting up a new vm with windows 8 (msvc 2010 does not support qwebengine) and may find out the the app won't run on XP....
and porting from QWebView to QWebEngineView....
Please help:
How to deploy webkitwidgets app on windows? (without installing Qt, which will be my last chance...)
Edit
Next step done was Running ProcessExplorer on the dev machine and on the target machine. Parsing the output of the loaded dlls on both machines, they do not differ. All required dlls are loaded? Still no display...
The problem should be solved in Qt5.5.1 which was released last week.
Just use the Deploy Tool of Qt :)
I have loaded vb6sp6 on a Windows 8.1 new development PC. Unfortunately when I attempt to open a project I receive the following error:
'C:\Project Folder\MSRTEDIT.dll' could not be loaded--Continue Loading Project?
That dll is located in C:\Windows\SysWOW64 but not the project folder, however copying it to the project folder still produces the error. On my previous Windows 7 64-bit development PC the dll is just located in C:\Windows\SysWOW64. If I click Yes to get past the error I receive the same error for MSCOMCTL.OCX I can successfully register the ocx but it doesn't get rid of the error.
Any suggestions??
The installation puts msrtedit.dll in the system folder so that PCs without Access can still run the program. The problem on my Windows 8 machine is that the msrtedit.dll file installed in the SysWOW64 folder was older than the one used by Office 2013, so even though the .exe file was able to run, I couldn't modify the exe in VB6 because of the newer version of Office. I still have more configuring to do, but I at least know where the problem is now. Thanks for getting me moving in the right direction.
I have a windows form application which is being installed on client pc by using msi file trough active directories, application is a 32bit app which is being deployed to a 32 bit and 64 bit windows systems and as we know application folder names are different between 32 and 64 bit systems, Program Files and Program Files(x86), also during installation application shortcut is placed in startup folder so app will be started when PC us powered up.
Question: Is there a chance to build msi by Windows Installer provided by Visual Studion in such a way that it will check what operating system its being installed at and place the shortcut in to start up folder with correct URI, to Program Files\Applicaiton\ or Program Files(x86)\Applicaiton?
Thank you!
Windows Installer packages are platform aware (x86, x64 ). Windows Installer doesn't support 64bit packages running on 32bit platforms or 32bit packages writing to 64bit ProgramFiles.
You can compile your EXE as AnyCPU and even though it's installed as 32bit it'll execute as 64bit. Although the Visual Studio team has moved away from that and compile as x86 by default in recent versions of Visual Studio.
Upon initialization, the Windows Installer gathers information about the operating system and automatically sets properties that can be used in optional conditional statements used by the setup application, such as VersionNT64 and "System Folder Properties"
In cases where it is necessary for the setup to know this information, it is preferred practice to allow the Windows Installer service to determine folder locations rather than try to hard-code this information into the package.
I have an application that I compile as x86 code but as a separate version, as x64 code as well. The application basically has two parts, a c# managed exe and a c++ unmanaged dll. I have problems with the latter. On my development PC (Windows 7 64-bit, Visual Studio 2008) I create a setup with a deployment project and this setup installs the application in Program Files... as it should and the application runs. I also have a test PC (Windows 7 64-bit with practically nothing else). There the application still installs into Program Files... but it does not run, I get the BadImageFormatException when a function (any function) of the unmanaged dll is called. The problem is that my own project that produces the dll also makes use of quite a few freely available libraries (e.g. glew32, openal, freeimage, etc.) I took as much care is possible to make sure that I use the x64 versions of these libraries, but something still must be wrong. For some reason one of the libraries used by my dll is not available as x64 code on the test PC but it is on the development PC. At least that is the only explanation I have at the moment why my setup works on the development PC but not on the test PC.
My question is: how can I find out where the problem is. The error message I receive does not tell any helpful detail. I tried to analyze my dll with depends but it looks OK. It lists a lot of dependent libraries as X86 (these are probably system files) but all those that I use on purpose are listed as x64.
Is there any way to test why the Windows on my test PC tries to run the DLL as x86 code even though it should be x64?
Thanks.
I noticed something very strange: My application is being deployed in the Program Files folder as it should be for a x64 application but it fails to run. However if I copy all the files in the folder it is installed to to another folder (inside the Documents folder) the application runs perfectly.
Run Fusion Log Viewer in the machine where you want to diagnose the issue. Look carefully at the logs and you'll see exactly which dlls are being loaded, and where from.
You have build your .NET executable (or DLL) with Any CPU configuration, and you have given x64/Win32 native DLL for Win32/x64 (i.e. wrong config).
On x64 systems, your .NET binary will try to load the native DLL as if native DLL is x64.
And on 32-bit systems, it will try to load 32-bit native DLL.
I found the answer. The problem was not the 64-bit dll at all. One of the libraries I did not make but I link to (I do not know which yet, there) seems to try to write a file to the application folder. Of course, this is not allowed inside the Program Files folder unless you run the application as an administrator. Sorry for asking help for the wrong question.
I have an application that allows me to scan images on my development PC which works successfully. It uses the Microsoft Windows Image Acquisition COM ActiveX dll. I am running VS2008 on Windows 7 64 bit.
I am having problems trying to deploy the Interop dll using ClickOnce. This component is referenced through the VS project in the normal way (and copy local = true). When I install the application on a Windows XP machine, I get an error saying that the library is missing (i.e. it wasn't installed / registered correctly). Having looked in the System32 directory, the dll is not there, so it has to be deployed via my app.
After looking on the web and trying various solutions, I then tried Microsoft's 'Registration-Free COM' method here: http://msdn.microsoft.com/en-us/library/ms165432%28VS.80%29.aspx
However, changing the Isolated property to True then caused 2 compilation errors due to duplicate entries in the registry. Having sorted out these entries out manually, I then deployed my app again with the supposedly isolated COM component, but when I try to scan a document I now get this message:
'The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll'
I feel like I'm going round in circles with this one. Can someone please enlighten me on how to deploy the WIA interop via ClickOnce for all versions of Windows from XP onwards?
Your help will be greatly appreciated.
Thanks
Don't copy system DLLs from your Win7 machine to the XP machine, that can't work. It would have been easier if you named the file, I would guess at wiaaut.dll, the WIA Automation provider. It probably just isn't installed on the XP machine.
Ask the client to install this download on the machine. You don't need reg-free COM, these are system components.