Visual studio 解决方案结构--子文件夹或子项目

我正在使用Visual Studio 2017创建一个解决方案。在这个解决方案中，我有几个子文件夹，每个子文件夹都包含解决方案不同组件的源代码

主解决方案基本上包含一个预处理器，它根据提供的文件参数调用所需的组件

foreach (string arg in args) 
{
  switch (arg)
  {
    case "ASN":
      ASNComponent.EntryPoint.Run();
      break;
    case "INV":
      INVComponent.EntryPoint.Run();
      break;
    case "ORD":
      ORDComponent.EntryPoint.Run();
      break;
    default:
      throw new Exception("The specified component doesn't exist");
  }
}

解决方案的结构如下：

MainSolution
|__ App.config
|__ Program.cs
|
|__ ASNComponent
|   |__ EntryPoint.cs
|   |__ Other files
|
|__ INVComponent
|   |__ EntryPoint.cs
|   |__ Other files
|
|__ ORDComponent
    |__ EntryPoint.cs
    |__ Other files

目前，该解决方案只包含一个项目，每个组件都存储在自己的子文件夹中，并使用自己的名称空间，然后由MainSolution包含一个using指令

---

使用其他项目而不是ASNComponent、INVComponent和ORDComponent的子文件夹有什么好处吗？从功能上讲，它甚至会有所不同吗？

在解决方案管理方面，使用项目可以提高粒度级别。例如，每个项目都可以有自己的引用，因此如果不同的项目需要不同的引用，则不必包含每个部件的所有内容。此外，您可以为解决方案中的每个项目选择不同的项目类型，因此，如果您编写的内容足够复杂，以至于您使用多种语言，那么您可以在构建解决方案时构建所有内容。此外，每个项目都可以有一个单独的生成目录。我相信还有更多的例子说明了使用项目的好处，这些只是证明我观点的几个例子

---

从您提供的代码来看，文件夹似乎可以满足您的需要，因为您尝试在交换机的单个案例中组织执行的代码，而不是创建产品，并为该产品构建WiX安装程序。这是一个在一个解决方案中包含两个组件的例子，可以保证它们自己的项目。

将一个大型项目分解为子项目可以强制进行模块化设计，这有利于可维护性，提供了重用的机会，并且可以显著缩短编译时间。