您的解决方案所需的 .exe 在 Visual Studio 解决方案中是否有合适的位置。例如，我现在正在开发一个需要 VHDCreate.exe、ISOCreate.exe、OSClone.exe 和其他 exe 的工具。将它们包含在解决方案中的正确方法是什么？我继承了一个解决方案，它们只是卡在解决方案的业务层项目内的文件夹中。
我使用的是 Visual Studio 2010。
【问题讨论】：
标签： c# .net visual-studio-2010 projects-and-solutions project-organization
我建议在解决方案级别有一个组织良好的工具文件夹。然后，您可以使用解决方案文件夹将其与其他项目分开组织。
【讨论】：
Copy if newer。
这是一个原生的.dll，但概念是一样的。
Copy if newer。.exe 或 .dll 将被复制到构建输出文件夹中。.exe 更新后，构建将在输出文件夹中拉取较新的。【讨论】：
您可能想阅读 Mike Roberts 系列，如何设置 .Net 开发树。就我而言，Visual Studio 默认的做法基本上是被破坏的。
单张*.pdf：How to Set Up a .Net Development Tree
基本上，您的目录结构应如下所示：
Meta/Development RootSolutionSolution.slnnant.buildliblib 目录包含解决方案中不同项目引用的第 3 方程序集/dll。它处于源代码控制之下。项目参考应该指向这里。toolstools 目录包含构建您的解决方案所需的所有第 3 方工具。它也受到源代码控制。 tools 目录应包含您的项目使用的 nAnt、nUnit 等版本 - 您的构建脚本应引用这些版本，而不是安装在开发人员机器上的版本。binbin 目录包含解决方案构建过程的输出。每个项目必须配置为指向此处。
debugreleaseobjobj 都将指向此处，并且它在源代码树中没有位置。遗憾的是，Visual Studio 并没有提供正式的方法来做到这一点（不过，有人告诉我，如果你有足够的资源，VS 可能会被黑客入侵）。srcsrc 目录是解决方案实际源代码的根目录。
project1project1 的目录。
project.csproj`*.cs 等文件。源文件。project-n我认为，如何构建单个项目是一个完全独立的主题，但是对于解决方案和单个项目来说，WRT 应该是命名空间和文件系统层次结构之间的对应关系。如果特定项目需要解决方案中的其他项目不可使用的第 3 方程序集，则可以为每个此类项目的目录设置一个参数到其自己的 lib 目录，但这会将第 3 方程序集分散在源中树，所以不推荐。
【讨论】：