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

Играет роль, что один проект на .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 подо все платформы, но с разным кодом? Т.е. с какой стати задачу разнесения бизнес-сущностей решать на уровне менеджмента проектов, а не менеджмента кода? Вы выносите бизнес-логику за язык программирования.

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

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

зачем интерфейсы одни и те же, они про должны быть одни!

Ты программист вообще?))

зачем интерфейсы одни и те же

Чтобы не писать документацию 100 раз. Описал один раз контракты и дело в шляпе.

они про должны быть одни!

Несколько раз перечитал эту часть предложения, но так и не понял что ты хотел сказать.

Ты программист вообще?))

В отличие от тебя да.

Я так понимаю что претензия к копированию интерфейсов. Они должны быть написаны один раз. А все проекты использовать эти, определенные один раз, интерфейсы.

Мы же не копировали в каждый проект stdio.h чтобы его заинклюдить.

Я так понимаю что претензия к копированию интерфейсов.

Но я нигде не писал про копирование интерфейсов :)

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


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

Как тогда может выглядеть структура проектов с пространствами имён? Например, так, как ниже? Т.е. разные проекты реализации, но с одинаковыми пространствами имён и, соответственно, полными квалификационными именами в классах, реализующих интерфейсы?

MyProject - the base name for the project (can also be a solution name)

project: MyProjectInterfaces

default namespace: MyProjectInterfaces

project: MyProjectImplementation1 - reference to MyProjectInterfaces

default namespace: MyProjectImplementation

project: MyProjectImplementation2 - reference to MyProjectInterfaces

default namespace: MyProjectImplementation

Но я нигде не писал про копирование интерфейсов :)

А это разве не про копирование?

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

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

Это следующий вопрос, который я бы хотел задать, но он слегка из другой темы. Ну да ладно.

В каких случаях добавление файла с кодом (именно с кодом, а не какого-то ресурса, хотя и с ними тоже вопросы) как ссылки нужно вместо добавления ссылки на проект, в котором этот файл находится? Т.е. зачем придумывать какие-то дополнительные механизмы распределения файлов или кода, когда уже есть один хороший? Тем более, что добавление файла с кодом не отслеживается IDE как установление связи между проектами.

Но я нигде не писал про копирование интерфейсов

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

А это разве не про копирование?

Нет. ЕМНИП исходники будут скопированы, если они находятся где-то в параллельном каталоге с проектным файлом. Т.е. можно сложить все проектрые файлы в одну папку и тогда при включении существующих файлов они не будут скопированы. Это мое предположение, я это не проверял.

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

Я привел пример, когда это может иметь смысл.

А вообще, это был вопрос ТС.

Как тогда может выглядеть структура проектов с пространствами имён?

Структура может быть такой:

.\SomeSolution
   +- SomeSolution.sln
   +- Implementation1.csproj
   +- Implementation2.csproj
   \Interfaces
     +- Interface1.cs
     +- Interface2.cs
   \Impl1
     +- SomeCode1a.cs
     +- SomeCode1b.cs
   \Impl2
     +- SomeCode2a.cs
     +- SomeCode2b.cs

А это разве не про копирование?

-----

Не-а. Просто ознакомься с тем что включается в проект и как указываются файлы и библиотеки.

все проектрые файлы в одну папку

-----

Пыхх...

Зачем так сложно?

Там вполне нормально используются относительные пути к фактическим файлам.

я это не проверял

-----

А Я - проверял.

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

Все детали - в MsBuild'e.

Структура может быть такой

------

Не-а... еще проектик добавь...

Не-а. Просто ознакомься с тем что включается в проект и как указываются файлы и библиотеки.

Не дождётесь. Никогда в жизни больше не буду что-то разрабатывать в продуктах мелкософта. Лучше опять на голых сях в емаксе писать. Развлекайтесь с этими дебилами сами :)

не буду

------

Ну и зачем себя так сильно ограничивать?

Структура может быть такой:

.\SomeSolution
   +- SomeSolution.sln
   +- Implementation1.csproj
   +- Implementation2.csproj
   \Interfaces
     +- Interface1.cs
     +- Interface2.cs
   \Impl1
     +- SomeCode1a.cs
     +- SomeCode1b.cs
   \Impl2
     +- SomeCode2a.cs
     +- SomeCode2b.cs

Вы шарите интерфейсы между проектами в виде файлов, добавленных как ссылки? А зачем? Можно же вынести их в отдельный проект, чтобы подключать потом к проектам имплементаций

Там вполне нормально используются относительные пути к фактическим файлам.

Там вполне нормально используются относительные пути к фактическим файлам.

Главный вопрос не в том, "можно?" или "не можно?", а "нахрена?". Вот в моём нынешнем проекте наворотили циклических зависимостей между проектами через ссылки на проекты и ссылки на файлы, так что теперь при переписывании хрен проверишь через компиляцию, правильно ли сделал, пока не напишешь весь цикл зависимостей. Или придётся отключать часть кода, чтобы скомпилилось. А юнит-тестов ваших благословенных нет.

Я понимаю, что нужно в проекте о себе оставить "память", мину замедленного действия, так сказать. Когда делаешь проект лет 5, да ещё с такими "наворотами", то становишься незаменимым. Потом другая команда хрен что перепишет без тебя. Сдал проект, получил гонорар. А потом сидишь и ждёшь, когда тебя позовут на сдельную работу за пятерную оплату - мины свои подчищать. Так семь знаков и зарабатываются. ))

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