我们正在考虑以这种方式组织我们的BIG项目:
\trunk [CompanyName] [Product1] [Project1] CompanyName.Product1.Project1.csproj [Project2] CompanyName.Product1.Project2.csproj CompanyName.Product1.sln [Product2]
我们试图遵循微软的建议,命名空间名称遵循文件夹结构,但是这样做有什么缺点吗? 您应用的解决方案和项目的命名约定是什么?
答案 0 :(得分:11)
如果你问我,那看起来很不错。特别是用全名命名项目,包括全名空间部分。当有很多项目时,我发现这很有用,特别是如果在不同的产品中碰巧有类似的项目。
你如何以及是否分裂产品和项目(我认为项目更像是一个应用程序而不是一个解决方案项目)非常接近你的组织规模,它是化妆和你的偏好。
答案 1 :(得分:4)
我使用的另一种方法是将所有解决方案文件放在同一目录中。
\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
答案 2 :(得分:3)
关于文件名 - 我更喜欢我的项目文件名与输出程序集名称匹配,因为它使得更容易知道产生什么。执行目录列表比在树中搜索生成我关心的程序集的csproj文件要快得多。
我没有对解决方案文件进行研究,因为它们不影响我们的构建环境,所以我最终自己拥有了我想要的确切范围(以及特定的每个解决方案项目,如测试元数据,我想要。)
关于文件夹结构 - 如果项目文件中的文件夹与命名空间匹配,我不会太担心。我希望我的代码以对项目最有意义的方式放在磁盘上。有时这意味着测试代码和产品代码位于兄弟目录中 - 有时它意味着它们相距甚远。有时会有一个由多个团队贡献的命名空间(不提倡设计,只是一个现实) - 但是那些团队出于某种原因想要在自己的文件夹中生活。
不要忘记版本控制分支策略在整个项目设计中的重要性。公司和产品边界可能是分支,因此不一定需要在磁盘上表示为目录。
不要让这成为分析瘫痪的根源。做出合理的选择。使用版本控制。如果你错了,你可以随时改变。
答案 3 :(得分:2)
看起来像是从学校的书中拿走的。这通常是我的解决方案的设置方式,并且我发现它多年来一直运作良好。
答案 4 :(得分:1)
对我来说很好。
需要注意的是,默认情况下,Visual Studio项目中的默认命名空间只是项目名称。当然,这表明将项目命名为命名空间是“Visual Studio Way”。
解决方案最自然地以产品/项目命名。就像你说的那样。
答案 5 :(得分:0)
我认为这样更好
\trunk
[CompanyName]
[Product1]
CompanyName.Product1.sln
[Main] --Optional
CompanyName.Product1.csproj
[Project1]
CompanyName.Product1.Project1.csproj
[Project2]
CompanyName.Product1.Project2.csproj
[Product2]
CompanyName.Product2.sln
[Main] --Optional
CompanyName.Product2.csproj
[Project1]
CompanyName.Product2.Project3.csproj
[Project2]
CompanyName.Product2.Project2.csproj
[Project3]
CompanyName.Product2.Project2.csproj
为什么?因为当您从存储库中获取代码时,例如会获得“ Product1”目录,因此该目录包含您需要工作的所有内容。 [Main]目录包含默认的基本名称空间,通常是exe或main项目。这是可选的。