I am getting "dll not found:restarting the application may fix the problem" error when i try to execute a simple "HelloWorld" win32 console application.
I know the location of the .dll.
How to specify its location when executing the .exe from command prompt?
PS: copying the .dll to the .exe's current dir seems to solve the problem, but this approach is not suitable in this case.
DLL loading happens deep in the plumbing of windows.
If the DLL is not found in the same directory as the application, the PATH is automatically scanned in order to find the directory.
So, the simplest answer to your problem is to add the directory containing the DLL to your PATH. Depending on when the DLL needs to be loaded by your code, you may be able to (temporarily) modify the PATH from inside your "HelloWorld" application.
The documentation for LoadLibraryEx has some discussion on how Windows searches for your dll. You might try using the LOAD_WITH_ALTERED_SEARCH_PATH flag if you can construct a full path to your DLL or use the SetDllDirectory function to add a directory to the search path.
To manually, permanently add your path to Windows PATH (permanently = until you remove it), right click My Computer>Properties>Advanced>Environment Variables>System Variables>Path>Edit>Variable Value, add a semicolon (which means "in addition to all before") and paste the full path of your dll.
Windows will search the path every time it can't find something in the current directory.
From: http://msdn.microsoft.com/en-us/library/7d83bc18.aspx
With both implicit and explicit linking, Windows first searches for
"known DLLs", such as Kernel32.dll and User32.dll. Windows then
searches for the DLLs in the following sequence:
The directory where the executable module for the current process is located.
The current directory.
The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
The directories listed in the PATH environment variable.
Related
What is the difference of the working directory vs the output path in visual studio?
Is it bad to set both setting to the same directory like '....\bin\'
By default they are the same. Assuming you're debugging some application it will be bin\debug.
Output Directory is where your output files goes. By default, Visual Studio builds each project in a solution in its own folder inside the solution. You can change the build output paths of your projects to force all outputs to be placed in the same folder
Working Directory is the location which Specifies the working directory of the program being debugged. It is the default place in which a program is looking up it's files. Normally the working directory is the directory the application is launched from \bin\debug by default.
So every opened file will be opened relative to the working folder.Let's say if you have an application installed in c:\myapp with all lib files in the same directory then you will set your working directory to myapp folder and you can do so from project properties.
By default, working directory is the output directory. Both can be changed, you can set another directory or common directory for all projects for output directory that determines a relative path for the output file that might be an executable or a static library.
Working directory also provides a relative path to put files that are used by the program. You can put a log file into a place that you can use its directory as a relative path in the code instead of absolute path. If your working directory is myproject\src and your log file is in myproject\src\log\log.txt then you can open or write the log file with log\log.txt in the code rather than c:\blabla\myproject\src\log\log.txt.
My Visual Studio 2013 Custom Build Tool step is failing because the directory in which the step is being executed is not the directory where the project file is (which was by default the case up until recently). I can patch it by adding a cd command to the start of the step to change to the project directory but I was wondering if anyone could tell me
how this directory path is set
how to change it.
The build always assumes the project directory as 'base' directory.
This gives msbuild a set location (Builds to bin\debug is a subfolder off 'Base', reference hint paths and a lot more besides).
I would just change the execute of your tool to be reference based (i.e ....\tool.exe or similar) or make use of the path environment variables ($(OutDir),$(TargetPath),$(ProjectPath),$(TargetDir) etc).
Another option that I make use of is to have a batch file called 'post.bat' that has the necessary steps to execute a custom tool. This is then placed in the project folder and added to the project as an artefact.
Without knowing exactly where your custom tool resides relative to the project (or solution) or what the 'working directory' requirements of the custom tool are I cannot suggest more.
I'm using Eclipse Juno for c/c++ under Windows 7. I've created a shared library project and an executable project. I've added the shared library project as a reference in the executable project via:
executable project's properties -> C/C++ General -> Path and Symbols -> References -> check the shared library project
All this works great at compile time, I can include my shared library project's class in the executable project, and use it etc.
However when I try to run the executable project in Eclipse, I get nothing. No error, no console output. After some googling I've discovered a similar issue here:
http://www.eclipse.org/forums/index.php/m/650331/
Apparently adding the shared library project to the executable project in Eclipse, as described above, does NOT also add the dll file to the executable (.exe) file's PATH at run time inside Eclipse. As an analogy with Eclipse for Java: if you have a Java JAR project A and another Java JAR project B, by making a reference from B to A in Eclipse, B's compiled jar file IS added to A's class path when running project A inside Eclipse. I thought it would be similar with Eclipse for C/C++ but apparently it's not.
Sure enough, if I manually take the .exe file and the .dll file, place them in the same folder and run the .exe, everything works ok. Also if I copy the .dll file in to Eclipse's compilation directory for the executable project, I can run the executable project from Eclipse and it's ok.
My question is then, is there a way to have Eclipse add that shared library project's dll file to the run time when I'm telling it to run the executable project? The discussed solution in the post I link to above is to manually add the shard library project's compile directory to the Eclipse's run configuration for the executable project, namely, to add it to the PATH variable there. But I find this cumbersome and not portable, if Eclipse is managing both projects it should be able to pass all that's necessary to the run time.
Well, I've went with the manual adding of the library project's dll to the excutable project's path at run time. I did find a way to make it more portable and project location neutral (i.e. if you move both projects' source folders to another machine, and reopen them in Eclipse there, it should still work):
right click on executable project -> Run as... -> Run Configurations
in the Environment tab click "New..." to add a new environmental variable
Name your variable "PATH" and give it a value similar to this:
${env_var:PATH};${workspace_loc:/cppAStar/Debug}
where:
${env_var:PATH} is Eclipse's way of saying "get the already existing value of the PATH environmental variable as declared in Eclipse"
the ";" is to separate the exisitng PATH entries from the new one we're about to add
${workspace_loc:/cppAStar/Debug} this tells Eclipse to get the location of the workspace project named cppAStar (here cppAStar is my shared library project) and then the "/Debug" refers to where this particular project creates the .dll file when it's built.
Issues that I couldn't figure out:
the "Environment" tab in "Run configuration" has an option called "Append environment to native environment". I thought that by checking this I'd only need to add the location of the .dll dir in the PATH variable I declare here, and it will be appended to the existing PATH. However I've not managed to make this work, hence the manual re-adding of all the existing PATH before appending the new value
Unfortunately that solution does not work for the debugg configuration. See Bug 338420 -Launch configuration's Environment tab variables are not passed to the gdb process itself.
Is there a way to solve this problem for debugging? I mean except from doing post-build steps like:
cmd /c copy "${BuildArtifactFilePrefix}${BuildArtifactFileName}" "${WorkspaceDirPath}\bin\"
I want to add linked files to a project with a environment variable in the path.
When trying with $(SourceLoc)\File.cs, the path is rejected.
When trying with %SourceLoc%\File.cs, the path is accepted but resolved to a full path.
I can close the project and edit the project file manually, add $(SourceLoc) to the path and it work fine. But isn't there any easier way?
Update
I found out it could possibly be done with a tool window extensions and DTE. I havn't tested it yet though.
Update
I have tried doing this with extensions now but it didn't work either:
Solution2 soln;
Project prj;
soln = (Solution2)_dte.Solution;
ProjectItem prjItem;
prj = soln.Projects.Item(1);
prjItem = prj.ProjectItems.AddFromFile(#"%SourcePath%\MyClass.cs"); // fail
prjItem = prj.ProjectItems.AddFromFile(#"$(SourcePath)\MyClass.cs"); // fail
Darnit...
In Visual Studio you're adding a file to a project using standard Windows Open File Dialog, thus $(x) doesn work, and %x% is being expanded to the full path.
So no, there is no other way then edit a project file manually.
I have an application which consists one .exe, many .dlls and a few folders.
I use NSIS to create an installer. It works but when I install the software, I don't see all the folders inside my application.
What do I have to do to bundle all the folders within my application into the installer?
This is the code I set the data source at this time:
File "c:\MyProject\MyApp\*"
The documentation tells us that the /r argument of the File command includes all sub folders and files. So you would use something like this:
File /r "c:\MyProject\MyApp\*"
The relevant section of the documentation can be found here:
http://nsis.sourceforge.net/Docs/Chapter4.html#file