Changing the .cscfg file is not enough to trigger the Changing/Changed events. You need to update the configuration in the compute emulator.
To test locally, open the compute emulator and find the deployment ID of your current deployment. This is the number in parenthesis following the label deployment (XX).
Now, open a Windows Azure SDK command prompt (make sure that you are running elevated), change the current directory to the folder that contains the .cscfg file, and then execute the following command:
Where is the cscfg file? I'm changing the one under the Bin/Debug folder of the CloudService project. I am then opening an Azure Command Prompt, changing the directory to the location of the cscfg file and running the command specified by Fernando Tubio.
With the latest SDK (1.7, June 2012) that results in the role shutting down and the debugging session closing.
Apparently. I ran a quick test with a File | New project and there appears to have been a regression here. After changing the configuration with csrun, the role never restarted and instead went into a loop with the status cycling endlessly between "Destroyed"
I'm glad that this is working for you now but the command should really work with
*any* valid configuration file, not just ServiceConfiguration.Local.cscfg. It shouldn't matter what the file name is or where it's stored.
Just in case, I tested again with ServiceConfiguration.Local.cscfg and I still see the same behavior. That is, whenever I update the configuration, the role fails to restart and instead goes into an endless loop. Moreover, it appears that I'm also unable
to restart a role by simply right clicking its deployment in the compute emulator and choosing “Restart”. Same result.
After further testing, I find that once a role goes into a loop, stopping the site manually from the IISExpress tray icon using “Stop Site” allows the role to eventually restart in the compute emulator. Note that you may need to attempt stopping the site a
few times before it succeeds (It appears that you need to do this while the status of the role is shown in the emulator as "Unknown", but I'm not certain about this). Even more curious is that once you do that, you can then update the configuration with any
configuration file, as I expected, and do this any number of times and it will work every time until you stop the deployment. Another interesting fact is that switching the project from IIS Express to Full IIS “fixes the problem” and everything starts to work
as I described in my first reply to this thread.
It seems that there’s something wrong with IIS Express, at least in my machine, and perhaps all this may be entirely unrelated to the problems that you were having, but can you confirm whether you are able to successfully restart a role in the emulator?
Also, what is your development environment? I'm running Visual Studio 2012 RC on Windows 8 RP.
UPDATE: I now realize that the term "Full IIS" may lead to some confusion. When I mention switching to Full IIS, I'm referring to switching the Local Development Server in the cloud project properties from IIS Express to IIS Web Server and *not* to
uncommenting the <sites> element.
Edited byFernando TubioSaturday, August 04, 2012 9:44 PMAdded clarification about Full IIS reference
I see. With a worker role, I can confirm your original report. That is, as soon as you update the configuration, the Visual Studio debugger detaches and the deployment is torn down. I cannot, however, reproduce your observation regarding the use of
the ServiceConfiguration.Local.cscfg file. In my environment, the behavior is always the same regardless of the configuration file used.
Nevertheless, if you start the project without debugging (CTRL + F5), you can update the configuration using *any* configuration file (e.g. Foo.xml) and the role will accept the change and continue to run. If you also need to debug, you can always
attach the debugger to the corresponding WaWorkerHost.exe process. Note that if you do this, I've noticed that the worker process recycles the first time you change the configuration, so the debugger will detach itself, although the role continues to run normally. You
can always reattach the debugger to its replacement. Fortunately, the worker process is not recycled for subsequent configuration changes so you can continue testing updates without too much friction.