Here’s a fun little thing I found out about recently. Suppose, I have a Cloud Service that I’m running on the devfabric and I want to simulate a configuration change.
I’ll start by creating a cloud service with a single web role:
Opening the service configuration file, I can see that the instance count is set to 1.
<Instances count="1" />
I hit F5 and my service has 1 instance of the web role running on the devfabric:
Note that the deployment ID is 51 – it’s in brackets in deployment(51).
To change the configuration while my apps is running, I open up the Windows Azure SDK command prompt (found in the start menu) and navigate to where I created my cloud service. An easy way to get there is to right click on the Cloud Service node in Solution Explorer and select “Open Folder in Windows Explorer”.
In that directory will be a ServiceConfiguration.cscfg file. This corresponds to the file in your cloud service project. Edit the value of your ServiceConfiguration.cscfg file (the one you edited before) and change the instance count to 3.
<Instances count="3" />
Now use the command line tools csrun to update the service configuration file. The command line help shows the command is:
You’ll remember above that in my case the deployment ID was 51. So my command will be:
> csrun /update:51;ServiceConfiguration.cscfg
csrun will then tell me that the new settings have been updated and when I look at the devfabric UI again, I hit refresh and I see that there are now 3 instances of the Web Role.
There are a couple of tricks here – because we are debugging this service, we started the role instances as suspended. Click on the Service Deployment, in my case deployment(51) and hit the play button to get those instances to run.
What you’ll also notice now is that if you hit “break all” in VS to stop in the debugger, VS is still only debugging one instance of RdRoleHost.exe which is the host process for the web role.
To debug the new web role instances while not stopping this session, go to the VS Debug menu and select “Attach to Process” and select the RdRoleHost.exe processes that are not currently being debugged and click “Attach”.
Hit “run” and now you’re debugging all of the role instances after making the configuration change.
Alright, I admit – a bit of a party trick to impress your friends with (now I have you guessing what kind of parties I go to) and not terribly useful in the July CTP as the role instances restart when the service configuration file changes. You may also see some cases where the dfagent crashes (these are not the droids you are looking for).
Letting the cat out of the bag here – in the upcoming release, you will have more control over what happens with your roles after a configuration change and it may be interesting to debug this scenario.