CS0122 при написании базовых модульных тестов «способом по умолчанию» для VS2022 и VS2025. ⇐ C#

[Anonymous]

Информация в первых соответствующих вопросах и ответах, которые я обнаружил, что InternalsVisibleTo не работает, сильно устарела. Обычно я тестирую код только с помощью операторов печати и защиты препроцессора #debug, но довольно сложная проблема привела меня в кроличью нору функциональности модульного тестирования.
Простое следование базовому руководству приводит меня к трудной для устранения ошибке, а не к продемонстрированному результату.
Предположим, я создаю базовый проект VS C# и использую такой код (например, простой пример точечной структуры, самая простая вещь, которая идет наперекосяк только для демонстрационных целей):

Код: Выделить всё

namespace myProject {
struct myPoint {
int x;
int y;
public myPoint(int newX, int newY) {
x = newX; y = newY;
}
// (... implement add, subtract, equals, etc...)
}
}

Далее я бы написал тестовый класс, который по умолчанию выглядел бы так... (опять же, в основном после базовой демонстрации)

Код: Выделить всё

using myProject;
namespace myProjectTest {
[TestClass]
public sealed class myProjectTest {
[TestMethod]
public void TestAddingPoints() {
myPoint pt = new myPoint();
// Test code goes here.
}
}
}

Как бы красиво и чисто это ни выглядело, это... идет не так. Вы получаете

CS1022 «недоступен из-за уровня защиты»

ошибку, которая может сбить с толку. И поиск в этом месте приводит вас к лабиринту устаревших советов из-за многочисленных изменений в том, как проекты работают внутри Visual Studio с течением времени, а также нескольких уровней абстракции между вами и тем, что говорит компилятор.
Попытка внести изменения, чтобы уменьшить ошибку на более низких уровнях (например, создать собственный файл buildInfo.cs вручную), может привести либо к перезаписи этих изменений, либо к потере некоторых других функциональность в среде IDE (поскольку действия, которые вы делаете на определенных экранах, заканчиваются внутри файла AssemblyInfo.cs, например, указание номера версии). Такое ощущение, что это неправильный подход.
В поисках разумных значений по умолчанию, что в 2025 году будет хорошим способом просто написать проект модульного тестирования и вместо того, чтобы придумывать свой собственный план, использовать уже предоставленные шаблоны по умолчанию и тому подобное, чтобы эффективно протестировать свой код, не тратя кучу времени, пытаясь понять (очень, очень сложные) внутренние особенности подписания сборки и то, как файлы проекта компилируются вместе, и при этом не делать что-то подобное как «просто пометить все как общедоступное», когда цель состоит в том, чтобы в конечном итоге иметь возможность написать некоторый производственный код, который не просто рекламирует все методы внутри. Помимо аспектов IP, существует также непрактичность не скрывать внутренние методы, которые бесполезны для потребителя.
Провожу небольшое исследование: просто добавив ссылку в VS, когда я копаюсь в файлах InternalsVisibleToAttribute, я обнаружил, что могу добавить в файл .csproj вот что, согласно интернет-источникам:

Код: Выделить всё

  

MyProjectTest

Это «что-то вроде» похоже на некоторые вещи из связанного вопроса, если вы прищуритесь достаточно сильно, но это определенно сильно отличается. За последние десять лет произошли изменения, которые сильно изменили «стандартный метод». Но что является современным стандартным методом?
Это не описанный выше метод, потому что он не работает (сюрприз, 2019 год тоже слишком устарел). Я не смог найти ничего нового, что подсказывало бы мне синтаксис.
Я также пробовал другую схему именования, при которой я даю имя своему тестовому проекту

Код: Выделить всё

myProject.tests

Вместо использования подчеркивания (думая, что какое-то «дочернее» пространство имен решит проблемы), но безрезультатно. Продолжение CS0122, если я не отмечу все как общедоступное.
Один (по общему признанию, очень глупый) способ решения этой проблемы — просто добавить

Код: Выделить всё

[assembly: InternalsVisibleTo("myProject.tests")]

Вверху буквально каждого файла проекта, который вы используете в тестах. Это похоже на 1970-е годы, поэтому должно быть лучшее решение, не так ли?
Если это актуально, версия .NET обычно — 4.8 (последняя с полнофункциональным API Win).

Подробнее здесь: https://stackoverflow.com/questions/797 ... and-vs2025