When you compile a DLL project, you will get a DLL and a LIB file as output. The DLL contains the actual library code; the LIB file contains stubs for the exported functions that assist the linker in emitting code to call that DLL.
This is very different from the LIB file that you get when you compile a static library. That LIB file contains all of the object code that comprises the library. All such code gets linked directly into your executable when you build it—hence the "static" part of the name.
However, the actual manner of usage is very similar. Regardless of whether you are linking to a dynamic or static library, you point the linker (using "Additional Dependencies") to the LIB file. The linker does the rest; it can tell from the LIB file what it is supposed to do.
Of course, you have to make sure it is the right LIB file. Having both projects (the DLL and the EXE) in the same solution will allow you to use project references, making the task essentially foolproof.
EDIT: You will of course not get a LIB file when you build a DLL unless the DLL exports functions. (If it doesn't export any functions, there's nothing for a client of that DLL to call, so there's no reason for a LIB file!) The simplest way to arrange for functions to be exported from a DLL is to use the __declspec(dllexport)
annotation. If combined with a macro, you can arrange for it to resolve to __declspec(dllimport)
on the consumer side, allowing you to use the same header file for both building the DLL and consuming it from an application. More information about that in my answer here. Alternatively, you can use a DEF file with an "EXPORTS" section.