Создание контрактов кода для устаревшей библиотеки

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

Что я пробовал до сих пор:

1. ContractClassFor атрибут.
   Не работает, потому что целевой класс должен указывать на класс контракта.

2. Вручную создайте ссылочную сборку контракта (например, MyAsm.Contracts.dll) путем обратного проектирования автоматически сгенерированных.
   Не работает, потому что сразу после того, как я его скомпилирую, перезапись срабатывает и удаляет атрибут ContractDeclarativeAssembly , что делает сборку нераспознаваемой инструментами как "ссылку на контракт" сборка". И не могу найти способ выключить перезапись.

3. Создайте «поддельную» сборку с тем же именем, версией, строгим именем (если есть) и другими атрибутами, что и целевая сборка, и поместите туда одноименные классы с одноименными методами. Затем скомпилируйте эту сборку с включенной опцией «Ссылка на контракт на сборку», затем возьмите сгенерированную ссылочную сборку контракта и используйте ее.
   По какой-то причине это тоже не сработало, хотя я понятия не имею, в чем именно заключалась эта причина. Статическая проверка просто игнорирует мою эталонную сборку, созданную smartypants, как будто ее не существует.

И еще кое-что, на всякий случай, это важно: целевая сборка скомпилирована для .NET 2.0, и я не могу ее перекомпилировать для 4.0.

Обновление

О написании библиотеки-оболочки с определенными контрактами не может быть и речи.

Во-первых, нужно написать много лишнего кода. Но даже если вы оставите это в стороне, это может привести к значительному снижению производительности: мне пришлось бы (потенциально) создавать классы-оболочки для каждого «устаревшего» типа, который используется в качестве возвращаемого типа из моих «устаревших» методов. Но и на этом история не заканчивается. Представьте, что некоторые методы могут возвращать ссылки на базовые интерфейсы, а затем вызывающий код может привести их к производным интерфейсам, чтобы увидеть, поддерживает ли объект дополнительные функции. Как мне их обернуть? Мне, вероятно, придется предоставить специальные методы Cast () для моих классов-оберток, которые будут пытаться преобразовать базовый класс / интерфейс и в случае успеха вернуть оболочку для результата. В конце концов, вся моя кодовая база станет настолько запутанной, что это, вероятно, все равно того не стоит.

С другой стороны, именно эта проблема уже успешно решена самой командой CC: они действительно поставляют правильные ссылочные сборки контракта для mscorlib, System.Core и некоторых других системных сборок, не так ли? Как им удалось их построить? Если они могут это сделать, то я не вижу причин, по которым я не смогу проделать тот же трюк.

Ну, вообще-то, я вижу одну причину: я не знаю, как это делать. :-) - Федор Сойкин 18 секунд назад редактировать