организация библиотеки(внешние модули)

[Пепел Феникса]

с другой стороны как обновлять устаревшие родительские ДЛЛ (несущие твой Base->Object), ведь это может повлиять на всю иерархию вниз.

иерархия врятли будет менятся.
если будет обновлен допустим тот же Base->Object, то по сути это обновления всей библиотеки.
соответственно если обновление же не просто так нужно будет.(тут скорее идет расширяемость чем обновляемость)
а сами приложения использующие библиотеку даже не заменят разницы.

[Stilet]

если будет обновлен допустим тот же Base->Object, то по сути это обновления всей библиотеки.

Не всегда. Есть случаи когда такое обновление радикально распространяется по всей иерархии. Не частые но есть.
Особенно в бухгалтерских программах - сам сталкивался с такими приколами.

[Пепел Феникса]

Не всегда.

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

[ds.Dante]

Думаю, в базовой DLL всегда можно оставить обратную совместимость для работы со старыми "дочерними" DLL.

Сообщение от Пепел Феникса

                        Base->Object
                         /    |     \
IO->Stream,FileStream,etc     |     String->String,Encoding
                      Files->File,Directory

В этом случае базу проще не выделять в отдельную библиотеку, а оставить прямо в экзешнике.

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

P. S. Как хорошо разглогольствовать об иерархии библиотек, которую вряд ли когда-нибудь буду делать! :)

[Пепел Феникса]

В этом случае базу проще не выделять в отдельную библиотеку, а оставить прямо в экзешнике.

и толку тогда от библиотеки?
она же не для одного приложения пишется.

Думаю, в базовой DLL всегда можно оставить обратную совместимость для работы со старыми "дочерними" DLL.

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