Совместное использование параметров конфигурации между различными компонентами в .NET - PullRequest
Новая
       6

Совместное использование параметров конфигурации между различными компонентами в .NET

2 голосов
/ 08 февраля 2012

Мне известно, что подобных вопросов по SO много, но у меня есть предостережение.

Основная предпосылка предсказуема: я унаследовал продукт, состоящий из нескольких компонентов, каждый из которых имеет несколько параметров конфигурации, среди которых главный в строке подключения. В настоящее время эти компоненты вызывают веб-службу с хешированным паролем для получения строки подключения (blegh), но это иногда вызывает условия гонки при запуске Windows между веб-службами и службами NT, требующие значений конфигурации.

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

Итак, в двух словах, мой вопрос заключается в следующем: как я могу создать централизованный механизм для параметров конфигурации, который также будет распространяться на развертывания по принципу "один клик"?

Опции, которые я рассмотрел:

Насколько я могу судить, оба эти решения зависят от наличия локальной копии общего файла конфигурации, которая не будет работать при однократном нажатии.

Две вещи, которые стоит отметить в нашей среде развертывания для приложения "нажми один раз":

  • Развертывания всегда выполняются в корпоративной сети LAN, поэтому такие параметры конфигурации, как строка подключения, универсально применимы.
  • Параметры конфигурации, которые упаковываются вместе с приложением «нажми один раз» после установки, могут быть переопределены при последующем развертывании.

1 Ответ

0 голосов
/ 14 февраля 2012

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

string mutexName = "C01F6FBB-50E9-4BFA-AFBA-209C316AE9FB";
TimeSpan waitInterval = TimeSpan.FromSeconds(1d);

// Server sample
System.Threading.Tasks.Task.Factory.StartNew(() =>
{
    // similate some startup delay for the server
    Thread.Sleep(TimeSpan.FromSeconds(5));

    using (Mutex mutex = new Mutex(true, mutexName))
    {
        Console.WriteLine("Server: Good morning!");

        // Do server business, ensure that the mutex is kept alive throughout the server lifetime
        // this ensures that the application can always check whether the server is available or not
        Thread.Sleep(TimeSpan.FromSeconds(5));    
    }
});

// Application sample
System.Threading.Tasks.Task.Factory.StartNew(() =>
{
    Console.WriteLine("Application: Checking the server...");

    bool mutexOpened = false;

    while (!mutexOpened)
    {
        try
        {
            using (Mutex mutex = Mutex.OpenExisting(mutexName))
            {
                mutexOpened = true;
            }
        }
        catch (WaitHandleCannotBeOpenedException)
        {
            Console.WriteLine("Application: Server is not yet ready....");

            // mutex does not exist yet, wait for the server to boot up
            Thread.Sleep(waitInterval);
        }
    }

    // Server is ready, we can do our application business now
    // note that we dont need to preserve the mutex anymore. 
    // we only used it to ensure that the server is available.
    Console.WriteLine("Application: Good morning to you!");
});

Console.ReadLine();

Надеюсь, это поможет!

...