Завожу в солюшене два проекта. В свойствах указываю одинаковые имена сборок и дефолтные простнаства имён. Создаю класс в одном проекте и затем копирую его в другой. Итого имеем полностью совпадающие полные квалификационные имена классов. Компиляция проходит нормально. Почему?

Играет роль, что один проект на .NET Framework, а второй - на .NET? Формально-то полная квалификация имени одинаковая, а про разные фреймворки никто не говорил.

они не partial?

Нет. Обычные публичные классы.

Я один большой солюшен переписываю с кучей проектов. С .NET Framework на .NET. И хочу в этом же солюшене параллельно создавать копии этих проектов, только на другом фреймворке.

Да, имена проектов разные (скажем, CommonLibrary и CommonLibrary.Net5), но они же не входят в полную квалификацию, а лишь имена сборок входят. А имена сборок одинаковые.

А что, Срывапокровов забанили? Теперь он с другого акка?

Не совсем понимаю, ты ожидаешь какой-то ошибки?

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

да, невежливо отвечал на тупые вопросы))

Не совсем понимаю, ты ожидаешь какой-то ошибки?

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

А, понял. Т.е. положим есть третий проект, к которому я могу подключить один из двух вышеупомянутых CommonLibrary и CommonLibrary.Net5 с одинаковым кодом. Про совместимость фреймворков сейчас не будем. Тогда мне нужно просто выбрать правильный проект, чтобы всё заработало без ошибок?

Блин, вроде самоочевидно, но что-то у меня из головы это вылетело. Просто никогда раньше такой дурниной, как содержание в одном солюшене проектов на куче разных фреймворков, в том числе несовместимых, да ещё с одинаковым кодом, не занимался. А тут те же вещи, но в другой обстановке - и уже непривычно, и сомнения берут - а продолжают ли эти вещи так же работать.

Почему?

------

А почему должно быть по-другому?

Я помнил, что в этом случае Студия ругается, но забыл когда. Ругается, когда пытаешься в одно место добавить ссылки на типы с одинаковыми именами.

А, понял. Т.е. положим есть третий проект, к которому я могу подключить один из двух вышеупомянутых CommonLibrary и CommonLibrary.Net5 с одинаковым кодом. Про совместимость фреймворков сейчас не будем. Тогда мне нужно просто выбрать правильный проект, чтобы всё заработало без ошибок?

Именно. Более того, я бы сказал, что это вполне себе респространенный случай :)

Если бы я делал компоненту, сборки которой отличаются исключительно компиляцией, то я бы сделал бы 1 солюшен, 1 исходник и Х проектов (скажем x86 и x64).

А файлы с кодом были бы лишь в одном проекте, а в другом - лишь ссылки на них?

-----

Сгенерировать идею об том, что они вообще ни в одном проекте что-то мешает?

Да. Или везде только ссылки.

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

Что-то не понял. А чем плохо переключение конфигураций архитектур x64-x86? Студия билдит все эти конфиги в разные папки - не перепутаешь. Может, можно и одновременный билд под несколько архитектур сразу настроить, без переключения - не знаю. Но суть в том, что зачем иметь кучу проектов с ссылками на файлы или ещё что-то, если можно просто сбилдить?

Какие-то невероятно навороченные архитектурно-сборочные пайплайны?

Какие-то невероятно навороченные архитектурно-сборочные пайплайны?

Представь себе, что ты пишешь ну например log4net. Можно конечно сделать 1 проект и переключать профили, чтобы получить 5-6-10 разных сборок, но тогда придется стартовать и бильд 5-6-10 раз. Гораздо проще сделать 5-6-10 проектов на одних и техже исходниках и за один старт получить все необходимые сборки.

Гораздо проще сделать 5-6-10 проектов на одних и техже исходниках и за один старт получить все необходимые сборки.

Неужели такие костыли до сих пор юзаются? Ничего нет, чтобы автоматом все или выбранные конфиги собирались?

Вот что нашёл

https://docs.microsoft.com/en-us/visualstudio/ide/how-to-b...

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

Я привел тебе просто один пример для чего это может понадобиться.

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

Не знаю, например ты можешь сделать адаптер для взаимодействия с базами данных - MSSQL, SQLite, Oracle, MySQL при этом ты хочешь выпускать одну сборку, которая включает все необходимое. Таким образом интерфейсы будут везде одни и теже файлы с интерфейсами и разные реализации.

Может, пример не очень удачный? Тогда и конкретные классы должны по-разному называться? Типа MSSQLAdapter, OracleAdapter, а не просто Adapter подо все платформы, но с разным кодом? Т.е. с какой стати задачу разнесения бизнес-сущностей решать на уровне менеджмента проектов, а не менеджмента кода? Вы выносите бизнес-логику за язык программирования.

Впрочем, я могу понять, что может где-то и применяется это. Осталось понять, а привально ли применили это в конкртеном месте. А то некоторые заморачиваются архитектурой ради архитектуры.

Конкретные классы можно называть по-разному. А вот интерфесы везде одни и те же. Плюс должна быть фабрика.