namespace CustomNamespaces

{

  class Program

  {

  ...

  }

}

На заметку! В случае замены комбинации Program/Main() операторами верхнего уровня назначить им какое-либо пространство имен не удастся.

Вложить пространства имен MyShapes и My3DShapes внутрь корневого пространства имен можно двумя способами. Первый — просто вложить ключевое слово namespace, например:

namespace CustomNamespaces

{

    namespace MyShapes

    {

        // Класс Circle

        public class Circle

        {

            /* Интересные методы... */

        }

    }

}

Второй (и более распространенный) способ предусматривает использование "точечной записи" в определении пространства имен, как показано ниже:

namespace CustomNamespaces.MyShapes

{

    // Класс Circle

    public class Circle

    {

         /* Интересные методы... */

    }

}

Пространства имен не обязаны содержать какие-то типы непосредственно, что позволяет применять их для обеспечения дополнительного уровня области действия.

Учитывая, что теперь пространство My3DShapes вложено внутрь корневого пространства имен CustomNamespaces, вам придется обновить все существующие директивы using и псевдонимы типов (при условии, что вы модифицировали все примеры классов с целью их вложения внутрь корневого пространства имен):

using The3DHexagon = CustomNamespaces.My3DShapes.Hexagon;

using CustomNamespaces.MyShapes;

На заметку! На практике принято группировать файлы в пространстве имен по каталогам. Вообще говоря, расположение файла в рамках структуры каталогов никак не влияет на пространства имен. Однако такой подход делает структуру пространств имен более ясной (и конкретной) для других разработчиков. По этой причине многие разработчики и инструменты анализа кода ожидают соответствия пространств имен структуре каталогов.

Изменение стандартного пространства имен в Visual Studio

Как упоминалось ранее, при создании нового проекта C# с использованием Visual Studio (либо интерфейса .NET Core CLI) название корневого пространства имен приложения будет совпадать с именем проекта. Когда затем в Visual Studio к проекту добавляются новые файлы кода с применением пункта меню Project►Add New Item (Проекта►Добавить новый элемент), типы будут автоматически помещаться внутрь корневого пространства имен. Если вы хотите изменить название корневого пространства имен, тогда откройте окно свойств проекта, перейдите в нем на вкладку Application (Приложение) и введите желаемое имя в поле Default namespace (Стандартное пространство имен), как показано на рис. 16.1.

На заметку! В окне свойств проекта Visual Studio корневое пространство имен по-прежнему представлено как стандартное (default). Далее вы увидите, почему в книге оно называется корневым (root) пространством имен.

Конфигурировать корневое пространство имен можно также путем редактирования файла проекта (*.csproj). Чтобы открыть файл проекта .NET Core, дважды щелкните на его имени в окне Solution Explorer или щелкните на нем правой кнопкой мыши и выберите в контекстном меню пункт Edit project file (Редактировать файл проекта). После открытия файла обновите главный узел PropertyGroup, добавив узел RootNamespace:

    Exe

    net5.0

    CustomNamespaces2

Теперь, когда вы ознакомились с некоторыми деталями упаковки специальных типов в четко организованные пространства имен, давайте кратко рассмотрим преимущества и формат сборки .NET Core. Затем мы углубимся в подробности создания, развертывания и конфигурирования специальных библиотек классов.

Роль сборок .NET Core

Приложения .NET Core конструируются путем соединения в одно целое любого количества сборок. Выражаясь просто, сборка представляет собой самоописательный двоичный файл, который поддерживает версии и обслуживается средой .NET Core Runtime. Невзирая на то, что сборки .NET Core имеют такие же файловые расширения (*.ехе или *.dll), как и старые двоичные файлы Windows, в их внутренностях мало общего. Таким образом, первым делом давайте выясним, какие преимущества предлагает формат сборки.

Сборки содействуют многократному использованию кода

При построении проектов консольных приложений в предшествующих главах могло показаться, что вся функциональность приложений содержалась внутри конструируемых исполняемых сборок. В действительности примеры приложений задействовали многочисленные типы из всегда доступных библиотек базовых классов .NET Core.