Various Visual Studio Questions ....
In an effort to get to know my tools better, I have a number of questions regarding Visual Studio (specifically vs2005).
1) What I have done in the past is copy and paste my project's dll dependencies into my project's debug/release build directories. How can I specify which dlls to link against without having to place the dlls in any of the default system locations?
2) I have noticed that you can specify libraries to link against using the following syntax: #pragma comment( lib, "glu32.lib" ). When is it preferable to use this syntax vs specifying libs in the settings dialog?
3) I have no idea what I'm linking against. I'm referring to the default libraries:
kernel32.lib
user32.lib
gdi32.lib
winspool.lib
comdlg32.lib
advapi32.lib
shell32.lib
ole32.lib
oleaut32.lib
uuid.lib
odbc32.lib
odbccp32.lib
Could someone briefly describe what each of these is?
4) What exactly is the runtime library? Is it better to link against the static or dynamic runtime?
5) If there are any other things you guys think a visual studio user should know, feel free to share those tidbits.
1) They need to be in the executable's path. That can be the same directory, or a system folder, or anything else that is in the path.
2) I think the #pragma directives are compiler specific and should probably be avoided if you want it to build in different environments.
3) Those are pretty much the windows libs... some are core OS libs while others are on the edges of what you might call the "OS". ODBC is database stuff... basically, VS puts everything in there for you that you need to link to to do windows development. You probably don't need to worry about the details until you need to worry about them, and you will probably know when that is. I'm just throwing out random links, but you can read more here.
4) Static builds into your executable. It will typically be faster but produce a bigger exe... DLLs are reusable and are loaded dynamically. If every app statically linked to windows libs, you would have a zillion copies of those libs from number 3 built into every app on your hard drive. As DLLs, they only sit in one place (in the system folder) and everyone shares them. Here... read this.
Whether you use static libs or DLLs is probably most often determined by size requirements, whether you own the lib code and other licensing concerns, and whether or not you might reasonably expect the lib to be required by another app on the end users machine. If you're just now learning, just use the DLLs.
Sorry, I know this is not the best answer, but I thought I'd give you something... you'll probably get much more well thought-out answers.
2) I think the #pragma directives are compiler specific and should probably be avoided if you want it to build in different environments.
3) Those are pretty much the windows libs... some are core OS libs while others are on the edges of what you might call the "OS". ODBC is database stuff... basically, VS puts everything in there for you that you need to link to to do windows development. You probably don't need to worry about the details until you need to worry about them, and you will probably know when that is. I'm just throwing out random links, but you can read more here.
4) Static builds into your executable. It will typically be faster but produce a bigger exe... DLLs are reusable and are loaded dynamically. If every app statically linked to windows libs, you would have a zillion copies of those libs from number 3 built into every app on your hard drive. As DLLs, they only sit in one place (in the system folder) and everyone shares them. Here... read this.
Whether you use static libs or DLLs is probably most often determined by size requirements, whether you own the lib code and other licensing concerns, and whether or not you might reasonably expect the lib to be required by another app on the end users machine. If you're just now learning, just use the DLLs.
Sorry, I know this is not the best answer, but I thought I'd give you something... you'll probably get much more well thought-out answers.
As for question 4:
There are few reasons to link the runtime library statically. As a general rule of thumb, you should always use the "Multithreaded [Debug] DLL" option unless you have a good reason not to. Dynamically linking it reduces code bloat, and since using a DLL allows Windows to share it with other processes it saves memory (since it's unlikely that no other program has the C runtime library loaded).
It's also more secure. I don't think this has ever happened before, but if a bug is found in the runtime library, it's possible for Microsoft or someone else to patch the bug in the DLL without needing to touch any programs that use it.
There are few reasons to link the runtime library statically. As a general rule of thumb, you should always use the "Multithreaded [Debug] DLL" option unless you have a good reason not to. Dynamically linking it reduces code bloat, and since using a DLL allows Windows to share it with other processes it saves memory (since it's unlikely that no other program has the C runtime library loaded).
It's also more secure. I don't think this has ever happened before, but if a bug is found in the runtime library, it's possible for Microsoft or someone else to patch the bug in the DLL without needing to touch any programs that use it.
Quote:Original post by smitty1276Quote:Original post by fpsgamer
1) What I have done in the past is copy and paste my project's dll dependencies into my project's debug/release build directories. How can I specify which dlls to link against without having to place the dlls in any of the default system locations?
1) They need to be in the executable's path. That can be the same directory, or a system folder, or anything else that is in the path.
I don't like the idea of polluting my system paths with random dlls. I also don't like copying dlls into the project's build directories, since thoes directories are essentially "temporary".
Is there a project setting in Visual Studio where I can specify the location of dlls?
Loading DLL's is handled by Windows and has nothing to do with Visual Studio, so you can't change the method it uses to search for DLL's. You also don't need to copy them into the build directory, since by default your app runs in the project directory (which is usually one level below your build directories).
You can add DLLs to your project and tell them to copy tot he output folder, if you want. Then any installer you create can automatically place those dependencies in the app folder.
Quote:Original post by smitty1276
You can add DLLs to your project and tell them to copy tot he output folder, if you want. Then any installer you create can automatically place those dependencies in the app folder.
Really? How do you do this?
Quote:Original post by fpsgamerQuote:Original post by smitty1276
You can add DLLs to your project and tell them to copy tot he output folder, if you want. Then any installer you create can automatically place those dependencies in the app folder.
Really? How do you do this?
You can add any kind of file to your project... then you can set those files properties (in the solution explorer) to be copied on build... the actual property is "Copy to Output Directory".
Quote:Original post by smitty1276Quote:Original post by fpsgamerQuote:Original post by smitty1276
You can add DLLs to your project and tell them to copy tot he output folder, if you want. Then any installer you create can automatically place those dependencies in the app folder.
Really? How do you do this?
You can add any kind of file to your project... then you can set those files properties (in the solution explorer) to be copied on build... the actual property is "Copy to Output Directory".
That option doesn't seem to appear for me.
But I did discover you can add a post-build event in the project properties to do the same thing. Under "Build Events > Post-Build Event", I added something along the lines of the following:
xcopy /Y "..\..\external-libs\devil\win32\lib\DevIL.dll" "$(TargetDir)"
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement