переключить DLL в зависимости от среды - .net

Question

Я хочу выпустить DLL, которая содержит некоторые классы для использования другими разработчиками.За этими классами находится еще одна DLL, которая содержит функциональность, на которую ссылаются.В среде разработки я хочу, чтобы эта внутренняя DLL имела ориентированные на разработку функции, но когда код переносится в производственную среду, я хочу, чтобы эта внутренняя DLL была реальной.Каков наилучший способ переключения этой серверной библиотеки DLL?

Спасибо за любую помощь.

Answer 1

Исходя из вашего комментария:

Я экспериментировал, и это кажется, что пока я определяю одни и те же классы, а имена DLL остаются то же самое, физически меняя DLL в каталоге работает нормально. Вы знать о любых проблемах, или недостатки этого подхода?

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

PROGRAM -> REFERENCED DLL -> [One of two "Backend DLL's]

Было бы создать абстрактные классы / интерфейсы в «REFERENCED DLL», которые определяют классы / методы, которые должны быть представлены обеими «Backend DLL», а затем иметь обе ссылки на внутреннюю DLL «REFERENCED DLL» и реализовывать фактические классы в вершина абстрактных классов / интерфейсов.

Например, «Программа» ожидает, что сможет использовать класс с именем «Logger» в REFERENCED.DLL, который использует методы из класса «BackEndLogger» в BACKEND.DLL (будь то разрабатываемая или производственная версия) , Итак, в REFERENCED.DLL есть такой класс:

public abstract class BackEndLogger
{
    public virtual void LogEvent(string eventToLog)
}

Тогда в обеих версиях "BACKEND.DLL" есть такой класс:

public class Logger : BackEndLogger
{
    public override void LogEvent(string eventToLog)
    {
    ... code for implementation goes here
    }
}

REFERENCED.DLL будет иметь ссылку на DLL, называемую «BACKEND.DLL», и, поскольку интерфейсы классов в точности одинаковы (в значительной степени обеспечивается синхронизацией их путем реализации абстрактных классов / интерфейсов в REFERENCED.DLL ) не будет мудрее.

Надеюсь, это имело какой-то смысл =)

Answer 2

Попробуйте пометить ваши классы «Только для разработчиков» с помощью ConditionalAttribute. Такие как:

[Conditional("DEBUG")]
public class DeveloperClass
{
    // ...
}

Вы также пометите методы таким образом. Это немного чище, чем использование # if / # endif. Таким образом, вы можете иметь общий доступ ко всему исходному коду, но изменить его, просто создав конфигурацию решения.

Answer 3

Итак, я полагаю, что и ваши dll для разработки, и для dll производства имеют один и тот же интерфейс?

Если это так, тогда просто поместите Оболочку над dll, и Обертка обернет все функции в dll (интерфейс одинаков для обеих версий dll).

Используйте следующий код для загрузки библиотеки,

if(PRODUCTION) {
        target_lib = "productionlib.dll";
} else {
        target_lib =  "developmentlib.dll";
}
lib = LoadLibrary(target_lib);

Оболочка просто перенаправит вызовы функций в соответствующую загруженную библиотеку (либо библиотеку производства, либо библиотеку разработки, как описано выше)

functionptr=(LPFunctionType)GetProcAddress(lib,"TargetFunction");
if(functionptr) { functionptr(bs); }

Answer 4

Использование файла .config для хранения имени сборки, которую вы хотите запустить, и при пустой / отсутствующей загрузке бэкэнд-версии. [подробнее] Это проще всего сделать с другой сборкой, которая содержит общие интерфейсы.