Одинаковые fully qualified type names - а ошибки нет?
зачем интерфейсы одни и те же
Чтобы не писать документацию 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, да ещё с такими "наворотами", то становишься незаменимым. Потом другая команда хрен что перепишет без тебя. Сдал проект, получил гонорар. А потом сидишь и ждёшь, когда тебя позовут на сдельную работу за пятерную оплату - мины свои подчищать. Так семь знаков и зарабатываются. ))
Может, Мурр нам просто подсказывает, как тоже богатыми стать? А то сидят дурачки молодые и средние, пытаются всё по фен-шуям сделать. И не ведают, идиоты, своего счастья в маленьких, но заковыристых закладках, которые их потом ещё несколько лет кормить будут.