CODEWITHSUNDEEP
visual-studiovisual-studio-2008msbuildc++-cliprojects-and-solutions
TownCube
TownCube

Reputation: 1320

Does Visual Studio 2008 support configuration (debug/release build) specific references?

I've got a native C++ project with one C++/CLI file (the only file compiled with /CLI), I'd like to add a reference to a C# DLL.

There are separate versions for debug and release however I can only seem to add one reference which is applied to all configurations. The reference search path dialog box contains a warning that if I attempt to use any $ConfigurationName type parameters they will only ever refer to the first configuration in the project.

So my current ideas are:

Any cleaner ways to achieve configuration specific references in Visual Studio 2008?

Upvotes: 3

Views: 1101

Answers (1)

stijn
stijn

Reputation: 35921

What I usually do is set the output path for all projects to the same location depending on the configuration. Eg for release builds everything goes into /path/to/Release and for Debug to /path/to Debug. Then I manually edit the project file to include a seperate targets file containing something like this:

edit shows how to use conditions to select debug/release dll with a prefix

<-- file myDll.targets -->
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
  <ItemGroup  Condition=" '$(Configuration)' == 'Debug' ">
    <Reference Include="myDll_d">
      <Private>False</Private>
    </Reference>
  </ItemGroup>
  <ItemGroup  Condition=" '$(Configuration)' == 'Release' ">
    <Reference Include="myDll">
      <Private>False</Private>
    </Reference>
  </ItemGroup>
</Project>

Then in the project that needs to reference this dll the targets file is included:

<Import Project="myDll.targets"/>

Because of Private=false msbuild won't try to copy anything, it just looks for myDll.dll and will find it in the output path.

This is not particularly clean but does work. The targets file can also be modified to reference different platforms (x86/x64).

Your first idea is probably what is mostly used as it requires the less hassle - except indeed that the projects should be in the same solution (as far as I know);

Upvotes: 3

Related Questions