为Visual Studio解决方案的命名约定和项目

问题描述：

我们想组织我们的大项目是这样的：为Visual Studio解决方案的命名约定和项目

 
\trunk 
    [CompanyName] 
    [Product1] 
     [Project1] 
      CompanyName.Product1.Project1.csproj 
     [Project2] 
      CompanyName.Product1.Project2.csproj 
     CompanyName.Product1.sln 
    [Product2]

我们试图按照微软的建议，即命名空间名称遵循文件夹结构，但没有作出任何缺点这样呢？您应用的解决方案和项目的命名约定是什么？

答

如果你问我，这看起来不错。特别是以全名命名你的项目，包括全名空间部分。当有许多项目时，我发现这很有帮助，特别是如果碰巧有不同产品的类似项目。

如何以及是否拆分产品和项目（其中我承担项目更像是不是一个解决方案项目的应用）是非常下降到您的组织的规模，这是化妆和你的喜好。

答

看起来像从学校的书。这通常是我的解决方案如何建立起来的，而且我发现它多年来运行良好。

答

对我很好。

这是一个一点要注意，在默认情况下，在Visual Studio项目的默认命名空间就是项目名称。当然，这表明命名你的项目像你的名字空间是“Visual Studio的方式”。

解决方案最自然地以产品/项目命名。像你指出的那样。

答

对于文件名 - 我喜欢我的项目文件名，因为它使得它更容易知道什么生产什么匹配输出程序集名称。做一个目录列表要比在一棵树中搜索csproj文件快得多，因为它生成我所关心的程序集。

我没有得到调动起来的解决方案文件，因为它们让我最终使我自己有确切的范围我想（和具体的每个解决方案项目，如测试元数据不会影响我们的编译环境，我想要的）。

对于文件夹结构 - 我不担心太多，如果领导下的项目文件的文件夹相匹配的命名空间。我希望我的代码能够以对项目最有意义的方式坐在磁盘上。有时这意味着测试代码和产品代码位于兄弟目录中 - 有时这意味着它们之间的距离会更远。有时候有一个由多个团队贡献的名称空间（不是主张设计，只是一个现实） - 但是这些团队无论出于何种原因都想在自己的文件夹中生活。

不要忘记版本控制分支策略在整个项目设计中的重要性。公司和产品边界可能是分支机构，因此不一定需要表示为磁盘上的目录。

不要让这成为分析瘫痪的来源。做出合理的选择。使用版本控制。如果你错了，你可以随时改变。

答

我用过的另一种方法是将我的所有解决方案文件放在同一个目录中。

\trunk 
    [CompanyName] 
    CompanyName.Product1.sln 
    CompanyName.Product2.sln 
    [Product1] 
     [Project1] 
      CompanyName.Product1.Project1.csproj 
     [Project2] 
      CompanyName.Product1.Project2.csproj 
    [Product2] 
     [Project3] 
      CompanyName.Product2.Project3.csproj

为Visual Studio解决方案的命名约定和项目

相关推荐