What are the best practices for choosing the linking method in VC++? Can anything/everything be statically linked?
On a dynamically linked project, is the relative/absolute location of the linked library important?
What are the pros and cons ?
added: I was mainly referring to lib files. Do they behave same as dll linking?
Dynamic links allow you to upgrade individual DLLs without recompiling your applications. That is why windows can be upgraded without your application being recompiled, because the dynamic linker is able to determine the entry points in the dll, provided that the method name exists.
Statically linking your application has a benefit in that calls to the linked code are not indirected, so they run faster. This may have an impact on extremely performance dependent code.
Using DLLs can also help you reduce your memory footprint, as effectively you only load the libraries as you need them and you can unload them when your done (think application plugins, only load an image browsing library when you have an image open etc.)
EDIT: Robert Gamble has added a comment which I missed: DLLs are loaded into memory shared by all processes in the operating systems. This means if two programs (or two instances of your program) use the same DLL, they will use the same DLL loaded into memory which will further reduce your overall memory usage.
The obvious advantage to dll is that you can upgrade individual components not just the whole application (in theory) and share common components (by encapsulating them in dlls). Unfortunately in practice there is a certain amount of binding between dll(s) (even when defined well). That leads you to need to upgrade dll in matching sets and isolating dlls that do no play well together.
If not done carefully upgrading DLL can lead to the problems known as DLL Hell.
In real life an application tend to put all the dlls they use in the same directory as the executable. This allows upgrading but does not promote sharing. Upgrading then consists of upgrading sets of DLL's in the application directory in sync with he DLL in the windows central repository.
DLLs can make for smaller runtime workingset, if the application were written in such a way as to manage the context switching between DLLs (For example, for larger applications, you could divide the applications functionality into logical boundaries to be implemented within self-contained DLLs and allow the loader to load at runtime).
While it's true that DLLs are primarily installed/copied into the same folder as the .exe, the requirement is to adhere to the loaders loading rules (which includes system folder (bad idea), PATH, current directory [see LoadLibrary API Help documentation for a full description of precedence]).
You "added" a comment regarding LIB files. In BOTH Dynamic and Static, you link using LIB files. But in the case of dynamic loading you deliver the .exe along with all dependent DLLs (the LIB files contain the exported entry points for the corresponding DLL).
I prefer DLLs as my applications tend to be larger and segmented and this allows me to deliver ONLY those updated components (DLLs). We even separate business logic from presentation in their own DLLs [permits localization of the resource-only dll independent of the logic.
Programming using DLLs DOES cause you to force yourself to adhere to the contract of the exported class/method or function.