8

Is there a simple way to add a path, globally (i.e. for all users on a machine), to the set of include/library directories in Visual Studio?

What I am looking for is the ability to safely add an include/library path to Visual Studio for all projects (past and future). This would be the equivalent of the INCLUDE, LIB, and LIBPATH environment variables that seem to work for command-line builds, but for some reason are completely ignored when building through Visual Studio. It must be applied to all users on a machine.

What I am NOT looking for is changing the user-specific MSBuild property sheets, Microsoft.Cpp.Win32.user.props, as this only adds the paths for a particular user on a particular machine. Though this seems to be the recommended way to accomplishing "global" settings, it cannot be applied in my use-case:

I am involved in teaching an introduction to programming for engineers class, with roughly 1000 students per year. We have a computer lab for them to work on weekly lab quizzes, but any per-user settings/documents are purposely cleared every time a student logs out (hence we cannot rely on the user-props). As part of the course, they need to work with a custom course library for interacting with a hardware unit (hence the need to add an include/lib path). Manually adding the paths for each project is beyond what we teach students, and would become tedious given that they will create several projects per week through the term.

What we have tried:

  • installing the required headers/libraries to the Windows SDK paths.
    This is definitely not ideal, and breaks whenever the Windows SDK is updated to a newer version
  • installing the required header/libraries to Visual Studio's Auxiliary path.
    By examining the default VC++ Include Directories, it seems like VS2017 includes the path C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\VS in its searches for headers and libraries. According to the docs, the folder is supposed to be for tools that are not truly part of the compilation process. This is what we currently do, but it feels wrong, and the folder location has changed with past Visual Studio versions, so may change in the future (we were stuck with VS2012 for the last 5 years because of this). We would also have to re-install the library whenever we update Visual Studio in the lab.

What we could try:

  • Adding the paths to the toolset default property sheets.
    Again, this is recommended against in various forums in favour of using the user-props ones (e.g. here). The sheets themselves warn not to modify them, there's a fear they can be reset whenever the toolset is updated, and if a new toolset is installed while upgrading VS, we would have to re-modify the default sheets for that toolset.
  • Creating a project template with the desired settings.
    We could create a template that students should choose when they create their new project through the New Project Wizard. The fear is that if students create a project with the wrong template (which will inevitably occur often with classes of such sizes), and begin their quiz tasks without the proper environment set, it will be a nightmare dealing with the issues that come up with our limited staff. Also, templates are VS version-specific (and placed in a version-specific folder), so we would have to re-install the template every time the visual studio version is changed.

The whole idea is to future-proof our workflow. What we want to do is incredibly simple: add a single header and a single library to the default search paths, and it should work with any version of Visual Studio installed on a machine. On any other system/IDE, this is a trivial task. Command-line MSBuild even supports it through Environment Variables. But for some reason, we cannot find a simple solution with Visual Studio.

Does anyone have a better idea?

Antonio Sanchez
  • 346
  • 4
  • 7
  • It seems to me like "safely" and "for all projects (past and future)" are difficult goals to reconcile. – François Andrieux Feb 01 '18 at 20:28
  • 2
    I wouldn't say so. The header/library are standard C89, not tied to anything Windows-specific. "Safely" as in won't break the next time IT updates Visual Studio, and is in line with what Visual Studio supports. "Future" as in we can ignore it for a few terms. – Antonio Sanchez Feb 01 '18 at 20:37
  • Couldn't you place the `Directory.Build.props` in ```C:\``` root? (and all other drives, won't work for e.g. student owned USB drives though) – Gizmo Jan 07 '20 at 09:49

1 Answers1

2

Create a "global" property sheet that contains all the necessary changes you need, and add it to any and all new projects.

For my example, I created a property sheet called core.props, and I saved it in the solution directory (but you could save it anywhere), and in this file, I added the includes and library names/directories (along with other settings, like specifying that Visual Studio use experimental C++ language features; specifying a precise directory for the output files; changing debug settings; etc.), and whenever I create a project that needs to make use of those settings, I just attach that property sheet to the project.

  1. For any project (or a new one), Open up the property manager from the Solution Explorer panel.
  2. Open up the desired configuration folder for any random project (probably Debug x64, but it's up to you) and "Add New Project Property Sheet" for that folder
  3. After you create the file, open it up
  4. Make whatever modifications you need every project to have
  5. Save the file
  6. For each other project that needs those properties, open up the same folder (or any other, if those settings are not specific to the configuration) and "Add Existing Property Sheet" to that folder
  7. Rinse, Repeat

You'll need to play around with the exact settings a bit to make sure it works the way you expect (do you need to specify a relative path or an absolute path for the libraries/includes/etc.?), but any time you create a new project, you'll only have to set that one sheet, and all the settings you need will be imported into the project. And if you need to make changes later, you'll only need to modify that one file to modify all of them.

Xirema
  • 19,889
  • 4
  • 32
  • 68
  • 8
    This is in no way global. We have a property sheet, creating one is not the problem. The problem is avoiding needing to manually import it for every new project. We would be better off with just using the project template, which essentially does this automatically. – Antonio Sanchez Feb 01 '18 at 22:17
  • @AntonioSanchez I don't know any way to make it even simpler. Importing a Property Sheet usually takes like 10 seconds for me, so I didn't bother looking for a method that was even faster or simpler. – Xirema Feb 01 '18 at 22:19
  • Thanks @Xirema, it would be for me too. The issue is mainly dealing with such a large class, many of whom are not tech-savvy, so everything needs to be done for them. – Antonio Sanchez Feb 01 '18 at 22:43
  • We have a similar problem. Our solution (which I'm still investigating) modifies registry keys HKCU/Environment/[LIB|INCLUDE|PATH|LIBPATH] with updated directories. This resolves BATCH (VCVARS) but we also appear to graft in a properties file automatically. I'm digging into that to understand what is done. I wasn't sure I liked the solution which is why I was looking here for best practices. There needs to be a way to plug in a global "per machine" properties file in my specific case that points to a repository of *.h/*.dll files created for all users. – Ross Youngblood Apr 17 '20 at 21:35