I need to run an executable as a pre or post build event.
I tried calling the executable from my project directory and the program could not find a certain .dll that I am using, even though both projects have a reference to the same .dll.
call "$(ProjectDir)SearchIndexBuilder.exe"
I just tried to call the same executable from the bin (target directory) and it ran without the dll error. Does anyone know why? I don't want to keep the executable there though, since I believe it would be bad practice.
call "$(TargetDir)SearchIndexBuilder.exe"
Also, can I traverse up/down directories in the build events? Can I concatenate '..\' or something similar to do so?
Related
I am a beginner in Objective-C language. I have downloaded and installed GNUstep msys and GNUstep core and installed them in order, as mentioned in the downloads page of GNUstep.
But, I think that the installation isn't correct, because whenever I try to compile an Objective-C source file, it shows fatal error Foundation/Foundation.h file not found. Means, due to some reasons, the path to the header files isn't valid.
Although I am now successfully able to compile the source file with the -I and -L options, I faced another problem. After compilation, when I run the compiled exe file, it shows an error that many dll files are missing, such as objc-4.dll, gnustep-base-1_24.dll to name a few of them. But, I found all of these files present under the /GNUstep/System/Tools folder. When I copied these dll files to my main working (home) directory, it runs successfully without any errors.
Why is this happening? All the tutorials I found on the internet shows very simply the compiling and running of Objective-C programs in Windows without changing so many things. Am I missing something? I have searched many times in StackOverflow and also on the internet, but none of those solved this problem. Please help me and thanks in advance.
P.S. - I have installed GNUstep in the default C:/GNUstep/ folder and included the C:/GNUstep/bin/ and C:/GNUstep/msys/1.0/bin/ folders in the PATH environment variable.
I noticed that there are more than one gcc.exe files present on my system for three different programming language compilers and their parent folders are included in the PATH environment variable. So, the gcc command conflicted with those three executables and therefore, the path to the dll files become invalid.
So, I had to move the GNUstep's bin directory to the top of the PATH environment variable to ensure that the GNUstep's gcc executable is used. And now, everything works like a charm.
I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.
I am working on a application built in VB.Net that allows a document to be uploaded and saved into a database. I did not build this application, but I do maintain it, put enhancements in it here and there. The target framework is .Net4
One of the functionalities within this process when uploading and saving the document it uses the method File.Open() to access the file and run other methods to compress it. The method that uses File.Open takes in a parameter that passes just the filename, not the entire path of where it came from.
When this application is running on an x64 machine I receive an error (System.IO.FileNotFoundException) when the code hits the File.Open method, complaining that it cannot find the file to open. It is expecting the file to be in the programs executing directory, which does make sense because it is only given the filename to go off, not the entire directory that it came from.
What's getting to me, is that this exact same application (exact same built assemblies) will run fine when run on an x86 system. It does not fail on File.Open() It still passes just the filename, but somehow, it will know the directory information.
How is this possible?
It's worth noting, that the method that contains the File.Open() method is in a different project in the same solution. It's a referenced DLL. e.g. MyApp.exe (Windows Form Application) references MyUtil.dll (Class Library). I have built against x86, x64 and AnyCPU configurations.
I understand that the fix to this would be to just pass the entire directory to the method, but what I need to know is how this is even possible? I want to better understand why this would happen, and hopefully this would help someone else better understand how assemblies may differ between different system environments.
EDIT: Using an absolute path did fix the underlying issue. See the comments below for some good information on this scenario
Windows has special handling for certain folder names on 64bit systems depending on whether you have a 32bit or 64bit process. Notably, the Program Files folder and the System32 folders map differently depending on what kind of process you have.
Note that this is a difference in Windows itself. It's not a behavior that is unique to .Net or Visual Basic. Any program platform that uses Windows native file handling will give you these results.
This is why you should use appropriate relative paths or the SpecialFolders enumeration, rather than hard-coding full path names, and be careful about where you put things you expect to reference later; you might find they end up in a different location than you expected. Often, the AppData or ProgramData folders are the more correct location, instead of the Windows or Program Files folders.
I send a Racket executable(in a distribution package) to a few friends and they get the error:"Failure: can not load the DLL". On my computer it runs without problems. It's using the rsound package.
Yes, good point. Currently, rsound is hard-coded to look in the collection path for the DLL. That won't work for programs compiled into executables. I've just updated rsound to tell it to look in "standard locations" as well for Windows and Mac.
Try this: Using the DrRacket package manager, update your copy of portaudio. When you're done, it should be at version "b9403a6dfbfb5eadf824ed91731ec141bf363677".
After this, it should be possible to pass along the executable file and run it, as long as the two required dll's are in the same directory as the executable. These two dll's are:
portaudio.dll
callbacks.dll
For windows, you'll find both of these in a subdirectory of the portaudio package. Finding these is going to be a teensy bit of a hassle on Windows; I believe these get installed in your user directory\RoamingData\\portaudio\lib\win32\x86_84\3m\ . If the target computer is a 32-bit machine, you'd substitute 'i386' for 'x86_64' in that path.
I know that Windows can make it quite hard to find the files you're looking for; let me know if you have any trouble.
Whew!
A wrong version of a dll (MSVCR90d.dll instead of MSVCR90.dll) gets used for the delete operator, causing a crash. In the callstack, only the dll name is shown, not their path. How to see the path?
Edit: I'm building in Release mode, not in debug mode. So why does the debug dll get used? I have seen the same problem reported on many other websites, but could find no working solution.
Yesterday I found using Dependency Walker that the debug dll is getting picked up, so I renamed the dll, then the release version got picked up in the Dependency Walker, and also my program did not crash. I didn't change anything today, but the program has started crashing again. And when I see the dependency walker tree, it shows MSVCR90d.dll (the debug dll) with a question mark, saying it couldn't find it in the path. Why can't it pick up the release dll? Also I don't know from where the debug dll gets used by the runtime.
You can add them in your global PATH environment variable. Refer here
You can specify the dll manually by right clicking on the solution and selecting Add Reference, then browse to the particular dll.
You can add the path to the DLLs to the Executables files settings under Tools > Options > Projects and Solutions > VC++ Directories
For finding out the details of a dll, you might want to use DependencyWalker
However, in your case I think d is being appended to the name of dll, probably because you are creating a DEBUG build, and for that corresponding DEBUG versions of all dlls are loaded.
If you choose to create a RELEASE build, you would not have a d appended to MSVCR90.dll
You don't need to know Dll path, you need to understand why Debug version of delete operator is called. Maybe, _DEBUG constant is defined in Release configuration.