Альтернативы чтению файлов конфигурации из библиотек классов во время разработки?

Question

У меня есть проект WinForm, который содержит несколько UserControls. Этот проект WinForm имеет ссылку на сборку (позволяет вызвать ее lib.dll), которая создается из другого проекта (Class Library), который существует в другом решении.

Теперь несколько из UserControls совершают вызовы в lib.dll, которые возвращают значения из файла app.config. Во время выполнения lib.dll работает нормально и возвращает необходимые данные, но во время разработки я получаю исключение от lib.dll, так как разделы app.config: NULL (за исключением исключений).

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

if(!DesignMode) { //code } 

Но это много контроля, чтобы пойти и применить это к. Есть ли что-то, что я могу сделать во всем мире, что было бы более элегантно, чем тестирование свойства DesignMode?

Редактировать

В ответ на два комментарии, оставленные ниже: решения, предоставляемые как представляется, не работает. Сборка, которая вызывает у меня проблему, живет в том же каталоге, что и app.config. Общая структура каталогов выглядит следующим образом

• Ссылки Папка
• Конфигурации (папки)
• appsettings.config
• app.config
• lib.dll

app.config тянет в нескольких другие файлы конфигурации (appsettings, cnx строки и т. д.), которые находятся в конфигураторе ионов. В случае моего исключения значение, которое я пытаюсь получить, находится в одном из этих вспомогательных файлов конфигурации, на который ссылается app.config.

Answer 1

Это интересный вопрос. Решение может быть создание в lib.dll статического класса, как этот:

public static class Config 
{ 
    private static readonly _param1; 

    static Config() 
    { 
     _param1 = ConfigurationManager.AppSettings["Param1"] ?? "Your default value"; 
    } 

    public static string Param1 
    { 
     get { return _param1; } 
    } 
} 

Затем в коде, InstEd писать ConfigurationManager.AppSettings [ «param1»], вы будете использовать Config.Param1. Поэтому вам не нужно будет тестировать свойство DesignMode.

Answer 2

Существует так много способов сделать это, ИМХО.

Одна мысль, которая сразу приходит в голову, заключается в использовании подхода на основе наследования для пользовательских элементов управления, о которых идет речь? Таким образом, в базовом классе вы можете установить регистрацию if (DesignMode) и выполнить правильное разветвление.

// if i were to visualizeyour lib.dll data initializer call like this: 
class BaseUserControl 
{ 
    // i'm guessing that you initialize the data somehow... 
    void InitializeData() 
    { 
     if (!DesignMode) 
     { 
      InitializeDataLocal(); 
     } 
    } 

    protected virtual InitializeDataLocal() 
    { 
     // whatever base behavior you want should go here. 
    } 
} 

// in the derived classes, just put the code you currently have for 
// fetching the data from lib.dll here... 
class UserControl : BaseUserControl 
{ 
    protected override InitializeDataLocal() 
    { 
     // fetch from lib.dll... 

     // optionally invoke some base behavior as well, 
     // if you need to... 
     base.InitializeDataLocal(); 
    } 
}