Visual studio 如何更改Visual Studio中的默认生成输出目录？

在Visual Studio 2010到2013中，默认情况下（例如，当我创建一个新的控制台应用程序时），新的解决方案将其编译后的可执行文件输出到

解决方案名称/Project name/bin/Debug/

中。我希望将它们输出到

解决方案名称/Debug/

，同样，对于所有其他构建配置（如“Release”）也是如此

我可以手动进入每个项目的属性，进入

构建

选项卡，将

输出路径

从

bin\Debug

更改为

。\Debug

。我必须对每个项目和每个构建配置重复这一点

经过几十个解决方案，我有点厌倦了每次手工完成这项繁琐的任务。有没有办法更改默认输出路径

---

适用于Visual Studio 2013的解决方案就足够了。

此属性在每个

例如，C#控制台应用程序模板位于

\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Windows\1033\ConsoleApplication\consoleapplication.csproj

csproj是一个XML文件，您可以随意编辑。构建输出目录的定义如下（对于每个配置）：

。。。
bin\Debug\
...
bin\Release\
...

如果您更改此文件，它将更改您未来所有新的C#Console应用程序项目。您还可以编写一个实用程序，列出

\program Files（x86）\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates

中的所有csproj，并相应地更新它们。

这不是必需的

解决方案中的一个项目被标记为启动项目，在“解决方案资源管理器”窗口中以粗体显示。EXE项目，如控制台模式应用程序。您使用Project+Add Reference向解决方案中的其他项目添加引用，以便可以使用这些项目在控制台模式应用程序中生成的类库

这些引用的“复制本地”属性将设置为True

生成项目时，MSBuild将自动将程序集从其各自的bin\Debug目录复制到控制台模式应用程序的bin\Debug目录中，这要归功于该复制本地设置。同时，它也非常聪明，可以查看这些类库的依赖关系并复制它们

因此，在构建完成后，bin\Debug目录不仅包含控制台模式项目的EXE文件，还包含正确执行所需的所有DLL

有几种方法可能会出错，而MSBuild无法确定这种依赖关系是否确实存在。非常罕见，例如，您必须在代码中使用反射来加载程序集（Assembly.load（）和friends）。解决方法是在生成后事件中显式复制依赖项。你没有在问题中留下足够的面包屑来判断这是否是真正的问题

你所要求的当然是可能的，IDE并没有让它变得容易，因为它的设计根本没有假设这是必要的。您必须将Build+输出路径设置替换为，例如，

。\Debug

。可以使用已预设的设置创建自己的项目模板。创建一个新的类库项目，更改设置并使用File+Export Template创建模板。您将在下次创建项目时使用它

---

但是，实际上，首先要找出默认的本地复制机制不适用于您的原因。

您可以创建自己的.targets文件，根据需要更改

，然后将其导入到项目中，而不是更改受保护的全局文件。这还可以为每个项目设置您可能想要更改和不想更改的其他默认值。然后在项目文件中只需添加类似于顶部的内容（当然，在根元素之后）：

将解决方案的所有项目输出到一个文件夹中是有意义的，这样可以节省一些时间和空间（想想SSD），因为内部解决方案依赖项只存在于一个输出文件夹中。这不是MSBuild的设计方式。你可以对抗构建系统，但它不是很有效率。不，你不能节省时间。复制生成输出文件是一种简单的内存到内存复制，在现代机器上的运行速度超过10 GB/秒。需要半毫秒，你永远不会注意到。文件系统缓存中的所有内容。无论如何，如果你想这样做，那么MSBuild不会阻止你，只是麻烦你。我想我的问题措辞是这样的，它假设它实际上是必要的。很明显，我现在想这样做的原因（将来可能还有其他原因）是我喜欢将输入文件输入到程序中，并将输出输出到文件中，这意味着我在调试和开发时经常访问这些文件。我想你会建议我将这些文件添加到我的项目中，从Visual Studio内部编辑它们，并允许在构建过程中复制它们-听起来是个好主意，尽管我不得不考虑一下它是否能解决我遇到的所有问题。这听起来相当可疑。确保将调试时使用的数据保存在与用户相同的位置。不会将其存储在与构建输出相同的位置。使用%appdata%是必须的。如果您的代码使用依赖项反转，那么这并不能解决问题。我正在研究一个解决方案，它的主要项目不（也不应该）依赖于解决方案上的某个其他项目进行编译，相反，另一个项目依赖于主要项目。但是，当运行时，dll需要在那里，它是动态加载的。谢谢，我想这就是我要找的-我今天晚些时候会尝试看看它是否有效（抱歉花了这么长时间）。你真的不应该修改全局的受保护文件。事实上，这可能会破坏服务，因此，如果模板更新以修复bug或更新新功能，则修改后的文件将无法更新。相反，您可以在自己的.csproj中设置

，它将覆盖全局设置（如果需要）

...
<OutputPath>bin\Debug\</OutputPath>
...
<OutputPath>bin\Release\</OutputPath>
...

<Import Project="$(SolutionDir)\Common.targets"/>