Здравствуйте, AutumnLeaf, Вы писали:

AL>Вопрос: можно ли всё-таки каким-то образом создать weak reference на эту либу, или unsign её и удалить из неё ключ, или как-то подменить её в рантайме?
Мы вроде делали такое... Надо через Using отметить нужные неймспейсы и классы:

using Project = PC.MyCompany.Project;

А сами юзинги обернуть в конструкции

#if DEBUG
...
#endif

Тогда при дебаге будет использоваться один тип, при релизе — другой. Естественно, в проект нужно присоединить обе сборки.

Здравствуйте, AutumnLeaf, Вы писали:

AL>Вопрос: можно ли всё-таки каким-то образом создать weak reference на эту либу, или unsign её и удалить из неё ключ, или как-то подменить её в рантайме?
Самый простой способ — conditional references: ссылка раз, ссылка два.

Нечто похожее обсуждалось на SO, но там полезных ответов нет.

В проекте используется 3-rd party library, которая коннектится к серверу компании, которая эту библиотеку предоставила.
Нужно написать тесты, которые бы проверяли, что при определенных входных параметрах объект запроса создаётся правильно и в нём ничего не забыли. Сам запрос можно не отправлять.
Библиотека вся построена на классах, не на интерфейсах, к тому же многие классы объявлены как sealed, internal или с закрытыми конструкторами и замокать ничего не получается.
Создавать фасад, который будет проксировать весь публичный API, и мокать уже его особо не хочется — слишком много работы.
В интернете нашёл эмулятор этой библиотеки, который содержит все теже самые классы с такими же именами и методами, но никуда не коннектится, а просто эмулирует запрос-ответ с полуслучайными значениями.
Появилась идея подсунуть эту библиотеку во время запуска тестов, подменив оригинальную. Однако, судя по всему это работает только с теми assembly, которые не strongly-named, то есть с этой либой не выходит. Попытался найти можно ли скомпилировать проект, который ссылается на strongly-named assembly обычным образом (как бы weakly) — ничего путного не нашел. Видел, что можно отключить проверку на уровне ОС, но это уже слишком — вариант не подходит.

Вопрос: можно ли всё-таки каким-то образом создать weak reference на эту либу, или unsign её и удалить из неё ключ, или как-то подменить её в рантайме?

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Здравствуйте, AutumnLeaf, Вы писали:

AL>>Вопрос: можно ли всё-таки каким-то образом создать weak reference на эту либу, или unsign её и удалить из неё ключ, или как-то подменить её в рантайме?
N_C>Мы вроде делали такое... Надо через Using отметить нужные неймспейсы и классы:
N_C>

N_C>using Project = PC.MyCompany.Project;
N_C>

N_C>А сами юзинги обернуть в конструкции
N_C>

N_C>#if DEBUG
N_C>...
N_C>#endif
N_C>

N_C>Тогда при дебаге будет использоваться один тип, при релизе — другой. Естественно, в проект нужно присоединить обе сборки.

Была такая идея, но все имена полностью совпадают...

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, AutumnLeaf, Вы писали:

AL>>Вопрос: можно ли всё-таки каким-то образом создать weak reference на эту либу, или unsign её и удалить из неё ключ, или как-то подменить её в рантайме?
S>Самый простой способ — conditional references: ссылка раз, ссылка два.

S>Нечто похожее обсуждалось на SO, но там полезных ответов нет.

Работает, спасибо. Этот подход натолкнул на такую мысль, что если нельзя weakly-named заменить strongly-named, тогда надо сделать наоборот и собрать проект с эмулятором, а потом уже подсунуть обычную либу

Здравствуйте, AutumnLeaf, Вы писали:

AL>Была такая идея, но все имена полностью совпадают...
Это как-то делает мой способ нежизнеспособным?