Note that the compiled executables will be in [project name]\release and [project name]\debug, but the working directory by default (where the dlls should be) is [project name]\[project name]

You can normally put the dlls in system32, however the executable will probably use the dlls in your project folder first if present; make sure both the lib and dll are the same version

You can put the .dll's in system32 as well, but for me, rather than mess with polluting my visual studio install directory with libs and my system32 with dll's that I use for development, I just put all my sdk's and libs in one place, and always include them explicitly through "additional include directories", and then always put my .dll's in the project folder.

This saves a lot of confusion as to what is included versus what isn't, especially when changing versions of things. Then I know exactly what I'm including all the time, and I don't have to look around deep in system files to try to find if I have old libs there or not.

To find out which dlls are actually used, I highly recommend sysinternals. They are free tools from Microsoft, which you can find here: http://technet.micro...ernals/bb795533
process explorer - great replacement for 'task manager', it tells you which dll's are loaded, which files are opened, etc. per process
process monitor - great tool which tells you the files/registry your process uses. Process explorer gives you a snapshot (does not show you which files were opened, only currently opened files), process monitor shows you entire history of the process.
There are plenty of other important tools there as well.

By explicitly you mean something like "C:/programming/my project/data/libs/somelib.lib", right?

I put the .dll's right in the folder alongside my visual studio solution (and in the debug/release directories if you want to run them as standalone exe's). For the libs I don't put them in the project folders, but rather in a central place that any projects can include (so I don't have them duplicated all over the place.

I just have :

C:\SDKs\glew-1.5.7
C:\SDKs\glew-1.5.8
C:\SDKs\Assimp-1.1.7
C:\SDKs\boost_1_44_0

etc. Inside these folders are the headers and libs to include. That's just personal preference though, you're welcome to do it however you like.

Can I specify somewhere to collect the dll from like "C:/programming/my project/data/dll/" as well? Or should it just be right there in the "root"?
[/quote]
I'm not aware of ways to specify a location for dll's, I usually just drop them in the project root. The thing about dll's is that you have to redistribute them alongside your binary for someone to run your exe on another computer. There's no such requirement for the libs (they get compiled into the .exe itself).
[/quote]
I'm allways eager to learn new and more efficient ways of doing things, and it seems like a much better idea to put them all in one place than to have them all over the place.

What I meant about the dll's was that if I could put them in a folder inside my project and point my project to them. That way they'd be redistributed but in a "safer" place than alongside the .exe. I'll take a look at if I can find anything about this.

Thanks for all the great help!

I googled around because this is also something I wondered about (is it possible to put DLLs in a subfolder rather than in the same folder as the program?) ..

Turns out the OS is entirely responsible for locating DLLs. So apparently, the only solution is to add the custom folder to the PATH environment variable (meaning it'll break on other machines unless they have the path set as well).

Hi all.
I've been trying for some time now to get GLEW to function correctly in VC++ 2010. I have no problems with this project in the older version i used to program in.
I get the following:
error LNK2001: unresolved external symbol __imp____wglewCreateContextAttribsARB
error LNK2019: unresolved external symbol __imp__wglewIsSupported referenced in function "public: bool __thiscall oglContext::create30Context(struct HWND__ *)" (?create30Context@oglContext@@QAE_NPAUHWND__@@@Z)
error LNK2019: unresolved external symbol __imp__glewInit referenced in function "public: bool __thiscall oglContext::create30Context(struct HWND__ *)" (?create30Context@oglContext@@QAE_NPAUHWND__@@@Z)

I know what an unresolved external symbol error is but this time I just don't know how to solve it.
When I compile my program. I've pragma commented the glew and opengl libraries in my main.h file:
#pragma once

// windowsfunktioner
#include <windows.h>

// input och output
#include <iostream>

// opengl och glew
#include <gl/glew.h>
#include <gl/wglew.h>
#pragma comment(lib, "glew32.lib")
#pragma comment(lib, "opengl32.lib")

Should the libs be located somewhere special? I mean other than the lib-folder in "Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib"?

I've included this file in the header file used by the document that is giving these errors (opengl.h)
#include "main.h"

class oglContext {
public:
...

And this header file is included in the opengl.cpp file that is giving the errors.
I think the compiler is complaining about the following lines:
GLenum error = glewInit();

if(wglewIsSupported("WGL_ARB_create_context") == 1){
hrc = wglCreateContextAttribsARB(hdc, NULL, attributes);
...
}

I'm out of ideas. Do you guys know why I'm getting these errors?

Thanks,
Marcus Axelsson

Hello, tre
Looks like it is not finding the glew library. In Visual Studio 2010 the include/library directories are setup differently that in VS2008, in VS2008 the directories were global in scope. In VS2010, each project has its own independant directory info. So go into your projects properties, goto 'VC++ Directories' and setup your directories to point to the windows sdk include/library directories, and see if this doesn't help. Don't forget to drop the glew include/libraries into the windows sdk include/library folders. Also, drop the glew dll's in the system32 directory (windows xp,vista,7).