visual-studio Visual Studio 解决方案和项目的命名约定

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/996479/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-10-22 10:38:52  来源:igfitidea点击:

Naming convention for Visual Studio solutions and projects

visual-studionaming-conventions

提问by Aleksandar Vucetic

We were thinking about organizing our BIG project this way:

我们正在考虑以这种方式组织我们的大项目:

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

We were trying to follow Microsoft's recommendation that namespace names follow folder structure, but are there any drawbacks for making it this way? What is the naming convention for solutions and projects that you apply?

我们试图遵循 Microsoft 的建议,即命名空间名称遵循文件夹结构,但这样做有什么缺点吗?您应用的解决方案和项目的命名约定是什么?

采纳答案by dove

That looks pretty good if you ask me. Especially naming your projects by their full name including full name space part. I've found this helpful when there are numerous projects, especially if there happens to be similar projects across different products.

如果你问我,那看起来很不错。尤其是通过全名(包括全名空间部分)命名您的项目。我发现这在项目众多时很有帮助,尤其是在不同产品中碰巧有类似项目的情况下。

How and whether you split on product and project (where I assume project is more like an application than a solution project) is very much down to the size of your organisation, it's make-up and your preferences.

您如何以及是否拆分产品和项目(我认为项目更像是一个应用程序而不是解决方案项目)在很大程度上取决于您组织的规模、构成和您的偏好。

回答by kenwarner

An alternative that I've used is to have all my solution files in the same directory.

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

\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

回答by Robert Horvick

With respect to file names - I prefer that my project file name match the output assembly name because it makes it much easier to know what produces what. Doing a directory listing is much faster than searching the csproj files in a tree for the one that produces the assembly I care about.

关于文件名 - 我更喜欢我的项目文件名与输出程序集名称匹配,因为这样更容易知道什么产生了什么。执行目录列表比在树中搜索生成我关心的程序集的 csproj 文件要快得多。

I don't get worked up about solution files because they don't influence our build environment so I end up making my own to have the exact scope I want (and the specific per-solution items, like test metadata, that I want).

我不会对解决方案文件感到厌烦,因为它们不会影响我们的构建环境,所以我最终使自己的文件具有我想要的确切范围(以及我想要的特定的每个解决方案项目,例如测试元数据) .

With respect to folder structure - I don't worry too much if the folders leading down the project files match the namespaces. I want my code to sit on disk in a way that makes the most sense for the project. Sometimes this means the test code and product code are in sibling directories - sometimes it means they are much further apart. Sometimes there is a namespace that is contributed to by multiple teams (not advocating that design, just a reality) - but those teams want to life in their own folders for whatever reason.

关于文件夹结构 - 如果引导项目文件的文件夹与命名空间匹配,我不会太担心。我希望我的代码以对项目最有意义的方式存放在磁盘上。有时这意味着测试代码和产品代码在同级目录中 - 有时这意味着它们相距更远。有时,多个团队贡献了一个命名空间(不提倡这种设计,只是现实) - 但这些团队出于任何原因都希望生活在自己的文件夹中。

Don't forget the importance of version control branching strategies in your overall project design. The Company and Product boundaries may be branches and therefore would not necessarily need to represented as directories on disk.

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

Don't let this be a source of analysis paralysis though. Make a reasonable choice. Use version control. You can always change later if you are wrong.

不过,不要让这成为分析瘫痪的根源。做出合理的选择。使用版本控制。如果您错了,您可以随时更改。

回答by Fredrik M?rk

Looks like taken from the school book. That's usually how my solutions get set up, and I have found it to work quite well over the years.

看起来像是从教科书上摘下来的。这通常是我的解决方案的设置方式,多年来我发现它运行良好。

回答by Tor Haugen

Looks good to me.

对我来说看上去很好。

It's a point to note that by default, the default namespace in a Visual Studio project is just the project name. Surely that indicates that naming your projects like your namespaces is "the Visual Studio Way".

需要注意的是,默认情况下,Visual Studio 项目中的默认命名空间只是项目名称。当然,这表明将您的项目命名为您的命名空间是“Visual Studio 方式”。

Solutions are most naturally named after the product/project. Like you indicate.

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

回答by prampe

I consider this is better

我认为这更好

\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

Why? Because when you get the code from repository you get, by example, "Product1" directory, it contains all you need to work. The [Main] directory contains the default base namespace, usually the exe or main project. It is optional.

为什么?因为当您从存储库获取代码时,您将获得例如“Product1”目录,它包含您工作所需的所有内容。[Main] 目录包含默认的基本命名空间,通常是 exe 或主项目。它是可选的。