Привлекательным аспектом разработки в .NET Core является понятие межъязыкового наследования. В целях иллюстрации давайте создадим новый класс Visual Basic, производный от типа SportsCar (который был написан на С#). Для начала добавьте в текущее приложение Visual Basic новый файл класса по имени PerformanceCar.vb. Модифицируйте начальное определение класса, унаследовав его от типа SportsCar с применением ключевого слова Inherits. Затем переопределите абстрактный метод TurboBoost(), используя ключевое слово Overrides:

Imports CarLibrary

'  Этот класс VB унаследован от класса SportsCar, написанного на C#.

Public Class PerformanceCar

Inherits SportsCar

  Public Overrides Sub TurboBoost()

    Console.WriteLine("Zero to 60 in a cool 4.8 seconds...")

  End Sub

End Class

Чтобы протестировать новый тип класса, модифицируйте код метода Main() в модуле:

Sub Main()

  ...

  Dim dreamCar As New PerformanceCar()

  ' Использовать унаследованное свойство.

  dreamCar.PetName = "Hank"

  dreamCar.TurboBoost()

  Console.ReadLine()

End Sub

Обратите внимание, что объект dreamCar способен обращаться к любому открытому члену (такому как свойство PetName), расположенному выше в цепочке наследования, невзирая на тот факт, что базовый класс был определен на совершенно другом языке и находится полностью в другой сборке! Возможность расширения классов за пределы границ сборок в независимой от языка манере — естественный аспект цикла разработки в .NET Core. Он упрощает применение скомпилированного кода, написанного программистами, которые предпочли не создавать свой разделяемый код на языке С#.

Открытие доступа к внутренним типам для других сборок

Как упоминалось ранее, внутренние (internal) классы видимы остальным объектам только в сборке, где они определены. Исключением является ситуация, когда видимость явно предоставляется другому проекту.

Начните с добавления в проект CarLibrary нового класса по имени MyInternalClass со следующим кодом:

namespace CarLibrary

{

  internal class MyInternalClass

  {

  }

}

На заметку! Зачем вообще открывать доступ к внутренним типам? Обычно это делается для модульного и интеграционного тестирования. Разработчики хотят иметь возможность тестировать свой код, но не обязательно открывать к нему доступ за границами сборки.

Использование атрибута assembly

Атрибуты будут более детально раскрыты в главе 17, но пока откройте файл класса Car.cs из проекта CarLibrary и добавьте показанный ниже атрибут и оператор using:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("CSharpCarClient")]

namespace CarLibrary

{

}

Атрибут InternalsVisibleTo принимает имя проекта, который может видеть класс с установленным атрибутом. Имейте в виду, что другие проекты не в состоянии "запрашивать" такое разрешение; оно должно быть предоставлено проектом, содержащим внутренние типы.

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

Теперь можете модифицировать проект CSharpCarClient, добавив в метод Main() следующий код:

var internalClassInstance = new MyInternalClass();

Код работает нормально. Затем попробуйте сделать то же самое в методе Main() проекта VisualBasicCarClient:

' Не скомпилируется

' Dim internalClassInstance = New MyInternalClass()

Поскольку библиотека VisualBasicCarClient не предоставила разрешение видеть внутренние типы, предыдущий код не скомпилируется.

Использование файла проекта

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

Закомментируйте только что добавленный атрибут и откройте файл проекта CarLibrary. Добавьте в файл проекта узел ItemGroup, как показано ниже:

    Include="System.Runtime.CompilerServices.InternalsVisibleToAttribute">