jump to navigation

Visual Studio Woes June 30, 2011

Posted by Jesse in : Uncategorized , trackback

I’ve been struggling with something lately, and I find it annoying.

Back in Visual C++ 2008 (and earlier), there was a feature that let you set up the include and library files that would be used by every project on your computer. Using this requiree that everyone on your team go through and set these paths up once, and then they were good to go. The benefit here is that if I install an external library at “C:\ExternalLibrary\includes” and my team member installs it at “C:\Libraries\ExternalLibrary\includes” it works just fine.

In Visual C++ 2010, that feature was taken out, and now you need to set up your external paths in the project settings. Unfortunately, the project file is something you’d include in version control. That means that when I set the path to my path of “C:\ExternalLibrary\includes” it’s going to break compilation for my team member when he grabs the latest version from version control.

I’ve done a lot of searching, and I can’t figure out a good solution in Visual Studio for this problem.

The best I’ve come up with is to handle this outside of Visual Studio with environment variables. I’ll add an environment variable like ExternalLibraryPath, set to “C:\ExternalLibrary”. And then in the project settings, I’ll add “$(ExternalLibraryPath)\includes” to the additional include directories. It works, but it forces all of my team members to set up an environment variable outside of Visual Studio, which feels a little dirty.

Anyone have a better solution?

Comments»

1. moswald - July 1, 2011

What I do is set up my projects directory like this:

projects\
Project_A\
external\
ExternalLibrary_1\
ExternalLibrary_2\
Project_B
external\
ExternalLibrary_3\
external\
CommonLibrary_4\

To be honest, I would recommend against a CommonLibrary area. Invariably, Project_A will want to upgrade to CommonLibrary_4 version 1.1, but Project_B will not.

2. moswald - July 1, 2011

Well that was silly. Let me try again.

projects\
   Project_A\
      external\
         ExternalLibrary_1\
         ExternalLibrary_2\
   Project_B
      external\
         ExternalLibrary_3\
   external\
      CommonLibrary_4\

3. Jesse - July 1, 2011

It seems pretty gross to duplicate a big library like boost for every project. But having the library internal would be nice if the original site went down, or the version you are using becomes unavailable.

I think I’ll switch to your method, and give it a go.

4. moswald - July 1, 2011

Well, in the case of extremely large libraries (like Boost), I would go against my recommendation and use the “external” at the project level. Our project at work uses Qt, and there’s no *way* I’d want to put that inside my app’s external folder. In that case, we do our versioning with version numbers as subpaths.