Visual Studio 2010 Compiling with the Debug or Release Version of Third Party Library Depending on If My Project Is Being Compiled Build or Release

Visual Studio 2010 Compiling with the Debug or Release version of third party library depending on if my project is being compiled Build or Release?

You can edit the csproj file manually set the Condition attribute on the ItemGroup containing the reference.

  <ItemGroup Condition="'$(Configuration)' == 'Debug'">
    <Reference Include="MyLib">
      <HintPath>..\..\Debug\MyLib.dll</HintPath>
    </Reference>
  </ItemGroup>

  <ItemGroup Condition="'$(Configuration)' == 'Release'">
    <Reference Include="MyLib">
      <HintPath>..\..\Release\MyLib.dll</HintPath>
    </Reference>
  </ItemGroup>

See this article for a bit more information.

VS 2010: Compiling Class Project, Debug Release, looking for path from my PC on other developer's computers?

references to the path of my project on my PC show up when another developer tries to use the Debug version of the DLL on their PC. I haven't worked extensively with compiling these DLLs, but I should be able to build a Debug release and give it to other developers to use within their projects, correct? Or is that not how it works?

When you build a debug version, you're also building the .pdb, which contains the symbols required for debugging. This is going to include the file paths, line numbers, etc, and be based on the system where this library is built. That's why they see these paths.

That being said, this won't hurt anything - they can use the assemblies to debug, but won't be able to see the code itself when something happens, as they won't have the projects.

Project settings in Release vs. Debug mode

Yes. Use the Property manager to add a new property sheet, making any changes you want, and then "Add Existing" to the other mode.

The listed sheets are just links and when a sheet is changed in one place, it's changed in all. The inheritance is hierarchical (probably not a word...) moving from bottom to top with the actual project inherited last and the lowest property sheet the first.

In the property page for the project (right-click on the project in the Solution Explorer → Properties) set every element that is in bold to "Inherit from parent or project defaults", and they will automatically inherit the properties from the next lowest property page in the property manager.

Mixing debug and release library/binary - bad practice?

Mixing debug and release code is bad practice. The problem is that the different versions can depend on different fundamental parts of the C++ runtime library, such as how memory is allocated, structures for things like iterators might be different, extra code could be generated to perform operations (e.g. checked iterators).

It's the same as mixing library files built with any other different settings. Imagine a case where a header file contains a structure that is used by both application and library. The library is built with structure packing and alignment set to one value and the application built with another. There are no guarantees that passing the structure from the application into the library will work since they could vary in size and member positions.

Is it possible to build your 3rd party libraries as DLLs? Assuming the interface to any functions is cleaner and does not try to pass any STL objects you will be able to mix a debug application with release DLLs without problems.

---

Related Topics