Ссылка на старую версию и новую версию одной и той же .NET DLL - PullRequest
0 голосов
/ 08 апреля 2010

Рассмотрим следующую ситуацию:

WidgetCompany выпустила .NET DLL в 2006 году под названием Widget.dll, версия 1.0.Я использовал этот файл Widget.dll в моем приложении .NET.Со временем WidgetCompany обновляла Widget.dll, и я не удосужился не отставать, продолжая поставлять версию 1.0 Widget.dll с моим программным обеспечением.Сейчас 2011, мой проект теперь является приложением .Net 3.5, и WidgetCompany выпустила Widget.dll версии 2.0.Он выглядит и функционирует почти идентично Widget.dll версии 1.0, используя те же пространства имен и имена типов, что и раньше.

Однако Widget.dll версии 2.0 имеет много критических изменений во время выполнения, начиная с 1.0, и я не могу простоперейти на новую версию;однако я не хочу продолжать разработку против версии 1.0 и поэтому продолжаю копать себя глубже в яму.То, что я хочу сделать, это сделать все новые разработки в моем проекте с Widget.dll версии 2.0, сохраняя Widget.dll версии 1.0 до тех пор, пока я не найду время для преобразования всего моего потребления 1.0 в более новый код 2.0.

Для начала я, очевидно, не могу просто ссылаться на Widget.dll (версия 1.0) и Widget.dll (версия 2.0) в Visual Studio.Это дает мне следующее сообщение: « Ссылка на« Widget.dll »не может быть добавлена. Ссылка на компонент« Widget »уже существует в проекте. » Чтобы обойти это, я могупросто переименуйте версию 2.0 Widget.dll в Widget.3.dll.Но это то, где я застрял.Любые попытки ссылаться на типы, найденные в «dll», приводят к неоднозначности, и компилятор, очевидно, не имеет ни малейшего представления о том, что я действительно хочу в том или ином случае.DLL новый "корневой" пространство имен или что-то?Например, если бы я мог сказать «Widget.dll имеет новое корневое пространство имен Legacy», то я мог бы обновить существующий код для ссылки на типы, найденные в Legacy.<RootNamespace> пространстве имен, тогда как весь новый код может просто ссылаться на типы из <RootNamespace>Пространство имен.Несбыточная мечта или реальность?Существуют ли другие варианты решения этой проблемы (кроме «не попадите в эту ситуацию»)?

1 Ответ

2 голосов
/ 08 апреля 2010

С моей головы это то, что я бы сделал.

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

Затем создайте проект, который является оболочкой для новой DLL-библиотеки виджетов.

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

...