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

Question

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

Теперь некоторые из 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 строки и т. Д.), Которые находятся в каталоге Configurations.В случае моего исключения значение, которое я пытаюсь получить, находится в одном из этих вспомогательных файлов конфигурации, на который ссылается app.config.

Answer 1

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

Одна мысль, которая сразу же приходит на ум, состоит в том, чтобы использовать подход на основе наследования для рассматриваемых пользовательских элементов управления?Таким образом, в базовом классе вы можете поставить эту 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();
    }
}

Answer 2

Это интересный вопрос.Решением может быть создание в 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; }
    }
}

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