.NET / Visual Studio: Better conditional compilation

A

Anton Shepelev

Hello, everyone

I want to have several "build parameters" that can
be adjusted independently, like these:

1. Debug/Release modes (R|D),
2. Version of the API my system uses (V7, V8, V9)

I have found a way to make them depend upon the so-
lution build configuration, using MSBuild's "Condi-
tion" attribute:

<COMReference Include="LIB8" Condition="'$(Configuration)'=='V8D'">
...

but that requires that one define the following
build configurations: V7D, V7R, V8D, V8R, e.t.c.
Should another parameter appear, it will become un-
manageable.

Is there a way to control each set of parameters
othogonally, without listing their scalar product in
build configurations? In other words, is it possi-
ble to define arbitary MSBuild macros? I would then
use $(TargetAPIVersion), $(Mode), e.t.c.

Thank you in advance.
 
A

Arne Vajhøj

I want to have several "build parameters" that can
be adjusted independently, like these:

1. Debug/Release modes (R|D),
2. Version of the API my system uses (V7, V8, V9)

I have found a way to make them depend upon the so-
lution build configuration, using MSBuild's "Condi-
tion" attribute:

<COMReference Include="LIB8" Condition="'$(Configuration)'=='V8D'">
...

but that requires that one define the following
build configurations: V7D, V7R, V8D, V8R, e.t.c.
Should another parameter appear, it will become un-
manageable.

Is there a way to control each set of parameters
othogonally, without listing their scalar product in
build configurations? In other words, is it possi-
ble to define arbitary MSBuild macros? I would then
use $(TargetAPIVersion), $(Mode), e.t.c.
Click to expand...

You can use And and Or in Condition and you can define
your own properties. Combined I think that should do it.

Arne
 
A

Anton Shepelev

Arne Vajhoj:
You can use And and Or in Condition and you can define
your own properties. Combined I think that should do it.
Click to expand...

Thanks. I am now defining whatever custom properties I
need in a separate xml file and importing that into the
projects. It's a shame that Studio is apt at turning
its .csproj files into a mess and one must edit them
manually to prevent that. And I also have to reload all
projects every time I change a property in the imported
MSBuild file, which is where your advice about using MS-
Build.exe isntead of Studio comes in handy.
 
A

Anton Shepelev

I said:
I am now defining whatever custom properties I
need in a separate xml file and importing that in-
to the projects. It's a shame that Studio is apt
at turning its .csproj files into a mess and one
must edit them manually to prevent that. And I
also have to reload all projects every time I
change a property in the imported MSBuild file,
which is where your advice about using MSBuild.exe
isntead of Studio comes in handy.
Click to expand...

While wrting a set of MSBuild scripts I found that
Studio 2008 seems to anchor relative paths in the
<Import> element to the location of the currently
parsed script instead of of the project. MSDN says:

Relative paths in imported projects are inter-
preted relative to the directory of the import-
ing project. Therefore, if a project file is
imported into several project files in different
locations, the relative paths in the imported
project file will be interpreted differently for
each imported project.

which seems wrong: relative paths in imported proj-
ects are interpreted the same way, from the location
of the imported project.
 
Top