Question

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:

• Join the two projects together under one solution and adding a reference to the “project” rather then the DLL assembly. My understanding is that Visual Studio will then match the configurations. Not ideal as my project and the DLL are “owned” by different areas.
• One project for debug (with only the debug configuration) and a release project (with only a release configuration) but that feels like a bodge.

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

Answer 1

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);