5

I am maintaining a large codebase and some vcproj files are used in different solutions. Due to some horrendous configuration and dependencies it seems the best way to handle some build issues is to #ifdef the code but in order to do that I need to set a preprocessor definition at the solution file level and not at the vcproj level.

Is that possible?

How to do it?

James McNellis
  • 348,265
  • 75
  • 913
  • 977
Tim
  • 20,184
  • 24
  • 117
  • 214

6 Answers6

5

I believe what you may want to do is create a project property sheet with the VS Project Manager that all the projects could inherit from. This would allow you to set any common project settings, including preprocessor macros, in a single location and inherit them as you need.

Daryl Hanson
  • 448
  • 2
  • 7
4

I finally find somethings that suits me

in my "C:\Users\\AppData\Local\Microsoft\MSBuild\v4.0"

I change it a little bit for:

<?xml version="1.0" encoding="utf-8"?> 
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(SolutionDir)\$(SolutionName).props"  Condition="Exists('$(SolutionDir)\$(SolutionName).props')"/>      
</Project>

So now, if a "mysolution.props" lays beside of "mysolution.sln" then I get a property sheet for the entire solution without changing anything inside my projects. It becomes a new features for my Visual Environement

Jan
  • 91
  • 4
  • how to check inside visual studio that this works? :) - i used a similar *.props file, but I don't know if I've used it right – rezna Nov 10 '15 at 14:14
  • Well, adding explicit `Import` elements to each project file in a solution where you want to do this would be safer, since that would continue to work if you migrated the solution between systems (or MSBuild toolsets). Like if your machine dies, you reinstall the OS, you want to work on the code on more than one machine (or OS version), or you want to collaborate with another developer. – SamB Dec 02 '15 at 20:17
  • (Also, you didn't mention what specific file you put that code in.) – SamB Dec 02 '15 at 20:19
  • This is a great solution. However, Visual Studio isn't aware of it, so intellisense may be a little wonky. You'll have to depend on the actual debugger as to what lines of code are actually active. – Paul Knopf Aug 05 '16 at 14:59
4

Select all the projects in your solution. Project + Properties, C/C++, Preprocessor, Preprocessor Definitions. Add

/DSOLUTION=$(SolutionName)

You can now test the SOLUTION macro value in your source code.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Wouldn't that _set_ this the preprocessor macro (instead off _adding_ to it)? If you do this, make sure the current state of the project files is checked in and safe. – sbi Sep 23 '10 at 16:03
  • @Tim: sbi has a point. If the setting is empty after you selected all projects then you'll have to append it for each individual project. – Hans Passant Sep 23 '10 at 16:22
  • I only need a setting for ONE project, not all projects i n the solution. I just need to be able to choose to compile (or not) based on which solution I am under. – Tim Sep 23 '10 at 16:39
  • Okay, this will be fine then, just ignore the "select all the projects" bit. – Hans Passant Sep 23 '10 at 16:54
1

Another approch:

Edit your vcxproj (or your vcxproj.user) with something like this

<PreprocessorDefinitions Condition="'$(SolutionName)'=='NameOfYourSolution'">
    YOUR_DEFINITION;%(PreprocessorDefinitions)
</PreprocessorDefinitions>

it's not perfect as it depends on your sln filename. It would be great if we use a $(SolutionConfiguration) variable instead.

Unfortunatly, I only see variable for project configuration: $(Configuration).

In any case, it does the trick...

Jan
  • 91
  • 4
1

2008 sln's are really dumb, they only have lists of projects/files to put in the solution explorer and project dependencies, so I don't think that's an option.

My gut instinct is to do something with relative paths. For example, in your stdafx.h's you could #include "....\project_configuration.h", then for building sln a, you'd check things out to one dir, and sln b another. Each would have its separate project_configuration.h.

I believe you could do something similar with vsprops files, which are essentially #includes for vcproj files, though I've found them a bit annoying to maintain over time.

Thomas
  • 3,348
  • 4
  • 35
  • 49
  • Yeah - I figured the sln files would not be helpful. Your other suggestions are interesting but we're back to the same issue - how to differentiate WHICH sln we are in while building a PROJECT. – Tim Sep 23 '10 at 15:50
0

Well, I also looked at

Define a preprocessor value from command line using MSBuild

and

msbuild, defining Conditional Compilation Symbols

and those might work as well, however our build system is pretty brittle right now and I am not in a position to change it all.

The solution I came up with was to clone the build configuration for the project in a solution and give it a different name. Then I added a macros/preprocessor definition to that new configuration.

It appears to work as desired. So one solution uses the old "release" configuration and the other solution uses a clone "ReleaseSpecial" (not the name I really used) configuration with different preprocessor defs.

Not ideal, but it works.

It would be nice if the propoerties were easier to deal with or SLN files could pass in preprocessor defs.

Community
  • 1
  • 1
Tim
  • 20,184
  • 24
  • 117
  • 214