Как известно C# множественное наследование не поддерживает, но мне надо всем классам в моей программе добавить ряд общих методов и полей. К сожалению все эти классы уже унаследованы от каких-либо других классов (Form, Component и т.п.), поэтому воспользоваться наследованием я не могу. Реализовать все это через интерфейс -- не удобно, т.к. придеться переписывать (копировать) реализацию в каждый мой класс. Я вижу следующие пути, но к сожалению не знаю как их реализовать:
1) Переопределить базовый класс Object
2) Использовать аналог C++ директивы #include
Прошу помочь с реализацией моей идеи.

А, может, лучше сэмулировать множественное наследование: http://www.codeproject.com/KB/architecture/smip.aspx?

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

Жду новых идей.

magnitudo, а какие ещё могут быть идеи кроме замены наследования агрегацией?  

Такие ограничения в наследовании зашиты в язык на концептуальном уровне...

Ну я предложил два варианта, которые я не знаю как реализовать.

magnitudo, 

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

magnitudo, попробуем решить проблему методом Йоды - скажи зачем тебе надо добавить методы и поля, как именно ты их будешь использовать - и мы убедим что поля добавить не нужно тебе. 

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

Extension Methods возможно помогут. Но имхо - если такая трабла - значит скорее всего просто где-то подход к решению задачи неправильный)

В общем мне нужны следующие поля:
ObjectID - уникальный код объекта
ConfigID - идентификатор конфигурационного файла (в перспективе это будет не просто файл, а допустим поток с удаленной машины) в котором храняться параметры моего объекта (файл .xml)
ConfigPath - Xpath путь к параметрам объекта, которые храняться в файле ConfigID

и ряд методов типа ReadConfig, WriteConfig.

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

magnitudo, а общая цель какая? Просто пробежаться по всем-всем-всем объектам приложения и подтянуть определенные свойства из конфига? Т.е. понятно зачем сохранять в конфиг свойства, например, контролов или форм. Или зачем сохранять туда какие-то данные. Но не уверен насколько нужно но запихивать все это в один конфиг.
Если все это делается для сохранения настроек - позиции, шрифтов - посмотри в сторону marker-интерфейсов и рекурсивного обхода дерева контролов. Выставляй свойства через reflection. 
Если для локализации, и ты собираешься подтягивать строки с какого-то сервера локализации - посмотри в сторону Custom Resource Manager.
...

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


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


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

1-в-1 одна из подзадач в проекте с моей прошлой работы  Был дизайнер форм. Формы со всеми вложенными контролами и их свойствами сериализовались в xml и хранились в базе...

таких вопросов как у вас ни у кого даже не возникало...

Ну и что мне с этим теперь делать   

Как человек более опытный, поделитесь секретом как вы отличали формы друг от друга (10 форм типа AnyForm) и реализовали контроль прав доступа пользователей к формам и контролам?

magnitudo, а какой смысл каждую из 10 форм отличать друг от друга?

у нас была ERP-шка, форма могла представлять из себя, допустим, форму для редактирования какого-либо справочника(читай "таблицы"). На разные действия с этой таблицей в БД прописаны права...а контроль возлагался на бизнес-логику и программа сама решала на основе данных из базы кому давать редактирование, а кому - нет...потом, вроде, этот функционал перешёл на уровень субд в виде хранимых процедур...но точно я уже не помню сейчас...это всё было как раз, когда я уходил уже...