C# Visual Studio解决方案-解决方案所需的实用程序执行器的正确位置

Visual Studio解决方案中是否有适合解决方案所需的.exe的位置。例如，我现在正在开发一个需要VHDCreate.exe、ISOCreate.exe、OSClone.exe和其他exe的工具。将它们包含在解决方案中的正确方式是什么？我继承了一个解决方案，它们只是卡在解决方案的业务层项目中的一个文件夹中

---

我正在使用VisualStudio2010

我建议在解决方案级别有一个组织良好的工具文件夹。然后，您可以使用解决方案文件夹将其与其他项目分开组织。

这是一个本机

.dll

，但概念相同

• 将现有项添加到解决方案，并选择存在二进制文件的任何文件夹：

• 从保存二进制文件的解决方案外部的任何文件夹中选择“添加为链接”

• 在解决方案资源管理器中，将其设置为

  Copy if newer

• 如果需要，将

  .exe

  或

  .dll

  复制到生成输出文件夹

• 当原始的

  .exe

  得到更新时，生成将在输出文件夹中提取较新的版本

---

您可能想阅读Mike Roberts系列，如何建立.Net开发树。就我而言，VisualStudio在默认情况下的工作方式基本上是不正确的

单个*.pdf：

基本上，您的目录结构应该如下所示：

• Meta/Development Root

  
  通常映射到源代码管理系统的根目录。

  • 解决方案

    
    一个目录包含整个解决方案。应命名为与解决方案匹配。

    • Solution.sln

      
      解决方案文件本身

    • nant.build

      
      解决方案的nant生成文件

    • lib

      
      

      lib

      目录包含由解决方案中的不同项目引用的第三方程序集/dll。它受源代码控制。项目参考应指向此处

    • tools

      
      

      tools

      目录包含构建解决方案所需的所有第三方工具。它也在源代码控制之下。

      tools

      目录应包含项目使用的

      nAnt

      、

      nUnit

      等版本，并且构建脚本应引用这些版本，而不是安装在开发人员机器上的版本

    • bin

      
      

      bin

      目录包含解决方案的生成过程的输出。每个项目必须配置为指向此处。

      • debug

        
        调试生成

      • 发布

        
        发布版本

    • obj

      
      在理想情况下，每个项目的

      obj

      都会指向这里，而这在源代码树中没有位置。遗憾的是，VisualStudio并没有提供一种正式的方法来实现这一点（不过，我被告知，如果你足够足智多谋，VS可以被黑客攻击）

    • src

      
      

      src

      目录是解决方案实际源代码的根目录。

      • project1

        
        

        project1

        的目录。

        • project

          .csproj`
          项目文件

        • *.cs

          等文件。源文件

      • project-n

---

我认为，如何构造单个项目是一个完全独立的主题，但解决方案和单个项目都应该有名称空间和文件系统层次结构之间的对应关系。如果某个特定项目需要解决方案中其他项目无法使用的第三方程序集，则可以为每个此类项目的目录创建一个参数，将其添加到自己的

lib

目录中，但这会将第三方程序集分散在源代码树中，因此不推荐使用。

可以轻松地将其合并到安装程序中吗？或者这只适用于XCopy类型的部署吗？哦，我以为你指的是构建。。。您确实应该为您的安装安装合并模块。请确保在解决方案资源管理器中标记它们

Copy if newer

。