转自：https://www.cnblogs.com/KevinYang/archive/2011/04/10/2011879.html

公司一些早期的项目，把所有工程都放到一个解决方案下了，导致整个解决方案编译很慢，而且也不便于类库的复用和维护。因此我们决定把工程按照功能划分到不同的解决方案里头，然后定期发布dll到TFS配置库上固定的TeamProject下面，以后应用程序引用时就不添加工程，而是采用添加dll的方式。但是现在遇到一个问题，发布dll一般会发布Debug和Release两个版本，那么应用程序应该引用哪个版本呢？

理想情况下，开发测试的时候应该使用Debug版本，这样抛异常的时候调试很方便。正式部署到生产环境的时候使用Release版本，这样性能好一些。但是添加dll的时候VS只允许选择一个版本。

我们知道，VS支持把工程不同的编译选项保存到不同的配置中，编译时根据当前使用的配置来决定采用什么样的编译选项。默认会新建Debug和Release这两个配置。开发时我们一般选Debug配置，发布时一般选择Release。

如果添加dll时也能根据当前配置引用不同路径的dll，那就好了。在stackoverflow上搜到了相关的信息，说可以修改csproj工程文件，使用VS宏变量来指定dll路径。用记事本打开研究了一番倒也挺简单的.找到引用类库的地方：

<ItemGroup>
  <Reference Include="ClassLibrary1,Version=1.0.0.0,Culture=neutral,processorArchitecture=MSIL">
    <SpecificVersion>False</SpecificVersion>
    <HintPath>Lib\Debug\ClassLibrary1.dll</HintPath>
  </Reference>

只需要改成：

<ItemGroup>
    <Reference Include="ClassLibrary1, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>Lib\$(Configuration)\ClassLibrary1.dll</HintPath>
    </Reference>

这样编译时VS就能根据当前配置到Debug或者Release文件夹下寻找相应的dll了。

不过这样一来，以后添加dll的时候就有点麻烦了，每次都要手工编辑csproj文件。有同事突发奇想，能不能在发布的时候再建一个名为“$(Configuration)”的文件夹，以后直接引用这个文件夹下的dll即可，都不需要修改csproj文件了。我的第一个反应是VS应该会对这样的路径做转义之类的，因为和内置变量名冲突了。但本着“不确定的事情要通过实验去验证”的精神，我做了这个实验，发现居然可以！VS才不管你路径包含什么字符串呢。

最后的结论，发布dll时，需要同时发布到以下三个文件夹：

• $(Configuration)\MyLibrary.dll
• Debug\MyLibrary.dll
• Release\MyLibrary.dll

其中$(Configuration)文件夹下的dll无所谓哪个版本了，这个纯粹只是为了骗过Visual Studio的而已，编译时根本不会用到。添加dll引用的时候，直接引用$(Configuration)\MyLibrary.dll即可。

希望此文对你有帮助。

这就很神奇了，我理解是1.VS在处理命名空间的时候将 $(Configuration)\ 解释成了字符串，作为文件夹名字 2.VS在编译的时候，又将$(Configuration)\ 作为宏来处理，解释为Debug 或者 Release 3.我觉得更大的可能性是处理命名空间和编译的使用使用的都是$(Configuration)\这个文件夹下面的dll，哪位有心可以做个实验：不提供Debug release目录，看是否可以编译。如果不可以的话，再将$(Configuration)\ 改为一个文件夹名字，这样提供三个文件夹，应该也可以工作的