Nello script #201 si è visto come, data la natura remota delle applicazioni Windows Azure, in sostituzione del web/app.config si possa usare il file cscfg e la classe RoleEnvironment per caricare informazioni da un file di configurazione, facilmente modificabile dal portale Azure.

Quando si modifica questo file attraverso l'edit inplace o l'upload di un nuovo file, non vi è alcun meccanismo automatico per l'applicazione delle modifiche. Nelle applicazioni ASP.NET si è abituati che ogni modifica al web.config comporta il reciclo dell'intera applicazione, mentre in applicazioni Windows occorre implementare un proprio meccanismo per reagire ai cambiamenti, strada spesso difficile da percorrere.

In Windows Azure invece la classe RoleEnvironment espone due eventi: Changing e Changed. Il primo notifica dei cambiamenti che devono essere applicati, il secondo che sono stati applicati. Per cambiamenti si intendono sia modifiche alla configurazioni dei ruoli (numero di istanze), sia modifiche ai settings. Quando con Visual Studio 2010 si crea un progetto Windows Azure è possibile già trovare l'intercettazione del primo evento Changing all'interno del RoleEntryPoint:

private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
{
  // If a configuration setting is changing
  if (e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))
  {
    // Set e.Cancel to true to restart this role instance
    e.Cancel = true;
  }
}

Prima di tutto il codice controlla all'interno della proprietà Changes, che restituisce una lista di tipi RoleEnvironmentConfigurationSettingChange e RoleEnvironmentTopologyChange, se ci sono cambiamenti nei settings. Impostando a true la proprietà Cancel ottiene così il riciclo dell'applicazione, con conseguente evento di stop e riavvio. Normalmente non avviene nessun riciclo, salvo che la topologia e in particolare l'istanza venga rimossa.

Se l'evento Changing permette di conoscere i cambiamenti, Changed permette di applicarli. Da migliore continuità di servizio infatti non riciclare l'applicazione, ma reagire ai cambiamenti per le successive operazioni. In questo caso è compito dello sviluppatore avere delle classi che permettano di cambiare le loro proprietà di funzionamento. Ad esempio la classe CloudStorageAccount, vista nello script #203, mette a disposizione il delegate configSetter per applicare le modifiche ed è possibile chiamarlo anche con l'evento Changed. La documentazione infatti consiglia sempre il seguente snippet:

CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
{
  // Imposto le configurazioni
  configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

  // Intercetto i cambiamenti
  RoleEnvironment.Changed += (sender, arg) =>
  {
    // Se è cambiato un settings con un nome utilizzato dal CloudStorageAccount
    if (arg.Changes.OfType<RoleEnvironmentConfigurationSettingChange>()
        .Any((change) => (change.ConfigurationSettingName == configName)))
    {
      // Applico le modifiche
      if (!configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)))
      {
        // Riciclo se non va a buon fine
        RoleEnvironment.RequestRecycle();
      }
    }
  };
});

Il codice ben documentato mostra come intercettare i cambiamenti e applicarli. Nel caso ciò non avvenga, per logiche interne, viene richiesto con il metodo statico RequestRecycle di riavviare l'applicazione.