Type Forwarding и не только

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

Можно, конечно, и так. Но лень :) Тут-то нам и приходит на помощь Type Forwarding!

Type Forwarding позволяет в нашей главной сборке указать, что нужный нам класс находится в другой .dll, при этом все остальные сборки по-прежнему будут считать, что наш класс объявлен в главной сборке.

Показываю на пальцах:

• Создаем два проекта MainDll и SecondDll
• Добавляем в список зависимостей SecondDll в проекте MainDll
• Объявляем какой-нибудь класс MyClass в SecondDll
• В MainDll добавляем такой код в файл AssemblyInfo.cs:

  [assembly:TypeForwardedToAttribute(typeof(MyClass))] 

• Компилируем всё что получилось

А теперь создаем какой-нибудь проект и добавляем в список его зависимостей ТОЛЬКО MainDll.dll и добавляем код вида:

MyClass mc = new MyClass();

Компилируем, запускаем, любуемся :)

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

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

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

В частности, такой подход я активно применяю в своем сортировщике mp3-файлов для чтения тегов я применял несколько различных сторонних библиотек (ввиду полнейшего отсутствия желания разбираться с форматом и поддержкой всех версий тегов). В процессе написания программы были опробованы 4 разных библиотеки, пока не был получен более-менее не глючный результат. При этом на смену библиотеки уходило около 5 минут - несмотря на то, что значительная часть кода (не связанного с пользовательским интерфейсом) работала с данными из тегов.

Более того, похожий подход я применил и при работе с медиабиблиотеками iTunes и Windows Media Player. Даже несмотря на то, что часть функций (в частности поиск по не полному имени артиста/песни) в медиабиблиотеке Windows Media Player не работала.