如何从C＃的单独文件夹中的文件导入命名空间

Question

当定义此类的文件在另一个文件夹中时，如何将扩展方法（请参见下文）引入当前的名称空间？

[当StringHandler.cs位于Product文件夹中时，我可以将using Utilities;包括在Product.cs中，但是当它位于单独的文件夹中时，与Project文件夹（在Utilities文件夹中）并排，无法弄清楚如何包含它。有人可以解释这种情况下如何使用using关键字吗？例如，using真正指向文件系统上的什么位置（我需要指定相对于csproj文件还是CallCenter.sln文件的使用目录？）

│   CallCenter.sln
│
├───src
│   ├───Project
│   │   │   Product.cs
|   |   |   Project.csproj
│   │   ├───bin
│   │   │   └───...
│   │   │
│   │   └───obj
│   │       └───...         
│   │
│   └───Utilities
│           StringHandler.cs

StringHandler.cs

namespace Utilities
{
    public static class StringHandler
    {
        public static string InsertSpaces(this string source)
        {
            string result = string.Empty;

            if (!string.IsNullOrWhiteSpace(source))
            {
                foreach (char letter in source)
                {
                    if (char.IsUpper(letter))
                    {
                        result = result.Trim();
                        result += " ";
                    }
                    result += letter;
                }
            }
            return result.Trim();
        }
    }
}

Answer 1

.cs文件所在的文件夹在编译过程中没有意义。 using语句仅允许从某个命名空间中找到类型。为了能够使用扩展方法，请确保：

• 包含名称空间（using Utilities;）
• 文件（StringHandler.cs）包含在您的项目中[[或在当前项目所引用的另一个项目中]

Answer 2

当定义此类的文件在另一个文件夹中时，如何将扩展方法（请参见下文）引入当前名称空间中？

与在文件夹中定义文件的位置无关。按照惯例，磁盘上的文件夹结构模仿名称空间，但并非必须如此。 using将类型“带入”命名空间。 （不是真正的“带来”-更像是“使……可用”）。

只要源类型可用于目标项目中的名称空间，它就必须通过a在物理上可用于您的项目

直接引用目标项目中的源项目
• 直接引用目标项目中的源NuGet包
• 通过另一个项目与目标项目的传递依赖间接引用源项目
• 通过另一个项目或目标项目中的NuGet包的传递依赖关系间接引用源NuGet包

和逻辑上由

源类型的using语句

当StringHandler.cs位于Product文件夹中时，我可以包括使用实用程序；在Product.cs中，但是当它在Project文件夹（在Utilities文件夹中）旁边的单独文件夹中时，我不知道如何添加它。有人可以解释一下在这种情况下如何使用using关键字吗？

由于您当前已定义结构，因此无法使用using进入StringHandler。原因是StringHandler是任何项目的一部分。因为它不是任何项目的一部分，所以它违反了我上面列出的规则。

要按预期使用using，您有两种简单的选择：

将StringHandler直接添加到需要它的项目中，或者如果您想将StringHandler分开，则将其添加到另一个项目中并从目标项目中引用该项目。

再加上一点功夫，将StringHandler保留在此处（无项目），并在目标项目中包括指向该文件的
• link
。这有点作弊：看起来StringHandler一直都在Project中。这种情况很少见；我个人仅在想要包括例如通用程序集属性而不是通用
• code

。时才这样做。

例如，在文件系统上真正使用过的位置是哪里（我需要指定相对于csproj文件或CallCenter.sln文件的使用目录吗？

同样，忘记目录/文件夹/磁盘结构。只考虑解决方案中的物理引用（基于项目/ NuGet）和逻辑引用（基于命名空间）。它们通常与目录/文件夹/磁盘匹配，但不必匹配。