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.
Related
When I use Visual Studio 2010 to debug a crash dump file (native code), it attempts to load C/C++ source files from the original build folder (and it gives the message "The source file is different from when the module was built. Would you like the debugger to use it anyway?"). The message is correct; the file is not the correct version.
What I would like VS2010 to do is to check out the source file using source server. If the file does not currently exist in its original build location, VS2010 will correctly use source server and retrieve the appropriate revision of the file (from Subversion). In order to force it to check out the correct revision, I have to physically delete the file from the original build location.
As a side note, VS2005 works as desired (well ... as I desire, perhaps not as others desire). VS2005 will always check out the correct revision from source control regardless of whether a copy of the file exists in the original build folder.
I believe the question comes down to one of the following:
Is there some kind of setting available that will change VS2010's precedence for finding source files?
Alternatively, is it possible to make VS2010 offer a choice/option to check out the source file in question? (Currently the only option I see in this situation is to browse for it.)
Or is it possible to completely exclude a specific path (folder) from the search?
I have the same problem with VS2010 and made an attempt to figure it out. I monitored devenv.exe with procmon but didn't see anything out of the order with the files & registry keys it was accessing. Pretty much the same information you see in the error report when VS2010 can't find the source. My solution is to use VS2005 as it works fine. I did see some correspondence on MSDN about a similar (if not the same) bug and they claimed it would be fixed in the final release of 2012. I believe I have that final release of 2012 and it has the same problem.
Here's a maybe slightly complicated solution
1) Create a script that will download and replace the pdb file (a .bat, a python script, whatever)
2) Create a new External Tool within VS2010 (Tools -> External Tools -> Add)
3) Point the tool to your script and pass any project-specific stuff to it as arguments
4) Create a post-build or pre-build step in your project that will call your new External Tool (project properties -> Build Events -> whatever)
This is a lot of work, but at least it will fully integrate it into your building process.
Note: Sometimes I've noticed that my post-build steps won't run unless I've compiled at least on cpp file. I usually press F7 and build some source and then build fully, to make sure everything works as expected.
You can change the local source directory to a different name when you are debugging crash dump file.
Or you can change the build directory to a different path with your local directory.
How can I consume a registration free COM object without copying the dll to the same directory as the executable? Is this possible?
I would like a complete working sample or a detailed step-by-step guide for my exact scenario.
For example, I have the following components:
CppTestRunner.exe - vc++ console application
CppTests.dll - vc++ mfc dll
CsCOMServer.dll - c# COM visible dll
I do not want to modify the exe or its directory, like adding an external manifest.
CppTests.dll is in a different directory than the exe.
It is okay if CsCOMServer.dll is in the same directory as CppTests.dll.
CppTestRunner.exe calls LoadLibrary on CppTests.dll which works fine.
After embedding manifests and using the windows activation context apis, I was able to copy CsCOMServer.dll to the exe directory to verify that CppTests.dll can create an instance of CsCOMServer.dll without issues, but again, I am trying to avoid this step.
Currently, with CsCOMServer.dll in the same directory as CppTests.dll, and without CsCOMServer.dll in the exe directory, I am getting the following error when I call CoCreateInstance:
Error = 0x80070002 The system cannot find the file specified.
I have used sysinternals process monitor to track down the paths CppTestRunner.exe looks in, etc.
I notice that depending on the things I try to do, sometimes CppTestRunner.exe tries to read CsCOMServer.dll.config in the same directory as CppTests.dll, but no matter what I try to put in there, I was not able to get past the error.
Also depending on other things I try to do, CppTestRunner.exe tries to read CsCOMServer.dll in the same directory as CppTests.dll but for some reason, I still get the same error.
Anyone know of working code with this exact scenario?
As you can probably tell, this is part of some unit\integration tests.
As a simple workaround, I am currently copying CppTestRunner.exe to the same directory as CppTests.dll and running it from there, but would like to avoid this step.
Thank you.
.NET looks for managed registration-free COM first in the GAC, then in the executable's folder. It uses the activation context to read activation metadata, but not to determine the location of the files themselves.
You can save the DLL in a sub Folder, let say DLLFolder\YourDll.dll, and in the manifest file of yourDll, write the filename like
<file name = "DLLFolder\YourDll.dll">
But you need to keep the manifest file (of the DLL) in the location where the EXE is saved.
So I see two solutions to my current problem, but I was wondering what the pros and cons are, or if there is a defacto best practices approach.
So my current project has a number of configuration files, help files, and other external content. I need this content local to run and debug the application. Currently we duplicate this content in a standard windows installer project. This clearly is a bad idea. We are moving to a new setup that uses the WiX installer, and I'm currently setting the project up next to the code project and trying to figure the best way to share resources. I see two solutions.
One is that I can put all the resources in the WiX project and then add them as links in the code project. This way I know what I'm debugging is installer.
The other option would be to leave the content in the code project and path into it in the installer using the reference variables.
Right now it seems 6 one way, half dozen the other. Any persuasive arguments for either method?
Assuming that these configuration and help files are going to be installed in the same directory as the executables then definitely put them in the code project, mark them as Content, and add a reference to the code project to the installer project. If you're using WiX 3.5 the files will be automatically included in the installer along with the executables, which makes writing simple installers much easier.
For earlier versions of WiX or more complex deployment scenarios (where the content files could be going into different directories) you would still put them in the code project but then you'd use File elements with a relative path or reference variable in the Source attribute to include the the content files from the code project directory.
I don't believe that putting the content files in the WiX installer project directory instead of the code project directory will do anything to ensure that the version you use to debug will be the same as the version installed. That can only be ensured by thinking through the process of how your application finds these content files and making sure the right versions are found.
So going back to the simple case where the content is in the code project and marked as Content, and it will be installed and loaded from the same directory as the executables, then it is only a matter of setting "Copy to Output Directory" to "Copy always" or "Copy if newer" and then you can be sure the versions used in debugging and the version installed will match.
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).
I'm trying to make a distribution directory with my application. I've copied several Qt DLLs to that directory, and the program seems to be working, with one exception: it doesn't seem to find SQL plugin for SQLite. Copying qtsqlite.dll to the directory, doesn't allow my application to open or create SQLite files. What must be the direcotry structure or which additional files need to be copied so that the program can read the database?
you can use depends.exe to see exactly what the dependencies of your exe are and make sure they're all included.
Also, read this page about qt plugins. they are supposed to be in a specific directory called "plugins" and not in the main directory with all the other dlls.
Most probably, the qtsqlite.dll itself depends on original SQLite DLL's which you probably need to copy as well.
Don't forget to include an LGP license copy in your distribution as well as pointers to the original download ressources of the libs you include and their sources. To stay with the law :-)
Thanks to the link #shoosh provided, I was able to fix the problem. I needed to create sqldrivers subdirectory in the distribution dir with qsqlite.dll library inside. But that was just step one. Do you have any tips and resources on creating a full-blown Windows installer? I'm mainly a Linux programmer so this area is unknown to me.