I am using QtCreator to run my application and have a CMake target that copies the DLLs next to my executable every time I press run.
This worked fine, but now I am writing unit tests and for each module, I have a separate executable.
So, the question is how can I avoid copying the DLLs to every single unit test folder, is there anything similar to Linux's LD_LIBRARY_PATH on Windows?
Nevermind, you can just add the build folder to your PATH and it will find the DLLs.
Related
I am trying to use dll files from OpenCV. To locate the dll files, instead of copying the dll file in a post-build event, a guy on YouTube did the same thing by going to System-> System Variables -> Edit Path -> Add YourLocationToDLLFile.
My code runs fine by editing my Path variable. I do not understand how editing the Path variable gives me the same result as copying the dll file in a post-build event.
I presume, since OpenCV is C++, your application is also unmanaged. In this case you should consult this article.
PATH directories are used as the last resort for DLL searcher to try locating the requested DLL. That's why it works for you.
Mind you, this is, obviously, good only for your local development, when you deploy your application, make sure it is properly packed with all the necessary dependencies, including OpenCV.
Hi I am trying to make my qt app run just copying the exe. With hours of static build I succeded it however; I discovered that there is a tool for mac named 'macdeployqt' doing all the process for you.
So I wondered if any equivalent tool or script exists for windows. It will get the exe extract dependencies, creates qt.conf file and put the dll's and exe into right paths.
What I mean here is not about creating setup package, just a folder containing all necesseray libraries etc.
The structure of my ANE file looks like this:
<META-INF>
<ANE>
<Windows-x86>
ExtensionDll.dll
DllUsedByExtensionDll.dll
extension.xml
mimetype
catalog.xml
library.swf
If ExtensionDll.dll uses the functions in the other Dll, the extension won't load. DllMain is not called. It seems like DllUsedByExtensionDll.dll is not in the Dll search path when the air application uses the extension is running.
How should I make the application find the extra Dlls, if I don't want to put them into some common Dll path?
I've had the same problem and went at this for a few days. Turns out there's two ways to solve this.
Export Release Build, while making sure that the DllUsedByExtensionDll.dll is packaged in the same directory as your executable.
For debugging purposes, copy the DllUsedByExtensionDll.dll into your Adobe AIR SDK bin directory, where the Air Debug Launcher (adl) executable is located.
You do not need to package DllUsedByExtensionDll.dll in the ANE that you are building.
The problem is that ExtensionDll.dll cannot find the DllUsedByExtensionDll.dll when it is launched from the debugger, since the executable for the debugger is located in the AIR SDK. Once you export the release build however, the your app is the executable, so now it looks for the dll in its root directory.
If you want to debug this in order to find out more information on what could be wrong, I suggest that you run your app by command line using the adl command.
For me, running through Flash Builder's debug/run meant that I could not see the Windows error "the program can't start because dll is missing from your computer". And that led me on a wild goose chase for a long time.
If your dll is using other dlls then include the reference dll's in the project where you are going to use that ANE file.
Is it possible to build projects to a common directory, instead of the per project bin folder?
The purpose would be to make it easier to source control all my binaries. How can I do it and, what are the pitfalls of this approach?
You have the option to build projects to another directory (a common directory?) rather than the bin/debug and bin/release.
If you mean building your projects and putting the DLL files in a shared folder, yes, we currently do this, but we use this using continuous integration (CI), so we can know when a change in a project caused another project to break.
You may also experience problems when you use a version-specific DLL file as referenced in your other projects.
You can also, rather than having a bat file copy over the DLL files, use Visual-Studio's built in post-build command. It's the same as a batch file, with the exception that no special setup is required in CruiseControl to copy over the files. If a developer makes a change to the post build command it and check it in it will automatically be executed by CruiseControl.
Also, if you'd like your developers to shared the binaries I'd put them in source control to make sure everyone share the same DLL files rather than their own local built copy of the DLL file (which might be different than the actual build server as some compile directives might/might not be defined).
If you mean DLL files/assemblies, then you build to bin/release as usual, then copy the DLL files you require to a common directory and then reference those, so when you rebuild the original solution, you don't have to worry about which version you are using or recompile other related projects as the version hasn't changed in the common dir.
It happens that people build to another folder than bin (e.g. the bin folder in the solution directory rather than the project directory). I doubt you would have any problems doing this. But since you're going to check it in, you must remember to not have it read-only (so you can build over them). Source control programs often lock the files.
You could also consider having a bat script that copies the files to another location after a successful build.
For C++ projects:
Right click on the project -> Properties -> Linker -> Output File
set your directory there.
For C# Projects:
Right click on the project -> Properties -> Builld -> Output Path
I would not put your binary output into source control. Only put the source files, project files and solution files.
We use post-build scripts to copy to the intended location. This works, but is very fiddly (as the scripts are awkward to write & awkward to debug).
How to run the exe file to other system?
Using VB 6
I copied the exe file to other system, then run that exe file, it not working it showing error
“component comdlg32.ocx or one its dependencies not correctly registered a file is missing or invalid”`
Can any one help me how to avoid this error?
When deploying VB6 applications, you should create a Setup, this will manage the DLL's that the VB6 application depends on. Since it is not enough to just copy the .Exe and .Dll's. You also need to register them.
The creation of the setup is included in the VB6 environment.
You can read this http://support.microsoft.com/kb/830761 which is very comprehensive.
1: http://support.microsoft.com/kb/830761 for more information.
Or if you just want the redistributable files check this kb http://support.microsoft.com/kb/290887
Copy and register the comdlg32.ocx on other system. Link: Fix Missing Comdlg32.ocx Run time Error in Portable apps.
Create an installer for your program.
Unless you are deploying your program to really old versions of Windows (prior to XP), one nice alternative is to create an XCopy package using reg-free COM. This is fairly easy for most simple programs using Make My Manifest though it can be done by hand or using other tools if you invest in a little study.
Even then a formal installer package is usually desireable though, if nothing else to create Start Menu shortcuts and set up application workspace directories.
Keep in mind that even the PDWizard is difficult to use blindly. Packaging and deployment is a topic that requires some learning investment.
Outdated or missing comdlg32.ocx runtime library is causing this error. Here is a copy of comdlg32.ocx (~60 Kb Zip). Download the file to the Desktop and extract the comdlg32.ocx to your the Windows\System32 folder.
Note: If you already have a copy of comdlg32.ocx, backup the existing file to a different folder and delete it from System32 folder.
1. Download comdlg32.zip and save to Desktop.
2. Unzip the file using WinZip or any other utility.
3. Extract comdlg32.ocx to Windows\System32 folder.
4. Type the following command from Start, Run dialog:
regsvr32 %Systemroot%\System32\comdlg32.ocx
Typically a VB 6 app will consist of an .exe some .dll libraries and a config.ini file. The exe is the starting place and it consumes the dll's and config.ini and other resources to run => you have to have all parts in the same directory for the app to run typically called "packaging" an app. E.g. An installer simply ensures that all those files in a packaged app are placed on a users computer in an Windows application directory, and creates a shortcut launch icon so that a user can click the shortcut in the start bar and the app will run.
To "package" your app (put the dll's and exe in the same folder) you can use an Add-In called "Package and Deployment Wizard":
And here is a demo of using it: https://www.youtube.com/watch?v=XT7jaoAiKDo
You can either package and create an installer and package or just create a package:
Now if the Deployment Wizard doesnt show as an add-in on your VB6 Editor Installation, go to editor's program folder and find the tools Tools folder, i.e:
Then you should be able to find the Deployment Wizard there:
Open it to use it.