How to manually change the worker role files on cloud by doing RDP?

Question

Pushing full cloud service project on to cloud is very time consuming, so if its some minor changes and I want them to reflect immediately then i RDP into the web role and make those changes and restart the IIS. Can something like this be done for worker role also? I can RDP and replace the dll files but I dont know how to re start the worker role as it doesnt run on IIS. I am not sure on what the worker role runs? I know this is not a good practice but as am still in development stage, this will immensely speed up my testing process.

Any easy ways to update the worker role on cloud rather than doing a full push?

Strick

Answer 1

Brent is 100% correct and I have upvoted his answer. You should be careful to not make any changes via RDP to a production service. Having said that, you did mention that this was just for testing purposes during your development phase, and there is a lot of value in being able to update a single DLL file and test without having to redeploy the entire cloud service. I do this all the time when troubleshooting on an Azure VM.

Check http://blogs.msdn.com/b/kwill/archive/2011/05/05/windows-azure-role-architecture.aspx for the architecture of the processes on the VM. In particular, note that WaHostBootstrapper is the parent process for both worker and web roles. To replace a DLL in either web or worker roles the best method is to:

1. Terminate WaHostBootstrapper. You can do this via Task Manager.
2. Replace the DLL. Note that you need to be quick when doing this because Azure will automatically restart everything shortly after you kill WaHostBootstrapper*.
3. Wait for WaHostBootstrapper to automatically restart, which will then automatically restart WaWorkerHost/WaIISHost.

*If you need longer time to make your change then you can attach a debugger such as WinDBG to WindowsAzureGuestAgent and leave it broken into the process. This will prevent Azure from automatically restarting the host bootstrapper process. After making your changes you can then detach the debugger and let WindowsAzureGuestAgent continue running. Note, that if you leave WindowsAzureGuestAgent in the stopped state for more than 10 minutes then the host agent will detect that the VM is unresponsive and reboot the VM.

*Edit: More detailed instructions are available at http://blogs.msdn.com/b/kwill/archive/2013/09/05/how-to-modify-a-running-azure-service.aspx.

Brandnew

Thanks a lot,this is exactly what i wanted!! But I am not able to find WaHostBootstrapper in the task manager processes. There is a WindowsAzureGuestAgent process though, does that start the worker role? – Strick

If you see WindowsAzureGuestAgent, but not WaHostBootstrapper then it is likely that your role is recycling. Check out the troubleshooting workflow at blogs.msdn.com/b/kwill/archive/2013/08/20/…. – Brandnew

If you need to stop it a little more than a few seconds you stop the WindowsAzureGuestAgentService and Then kill the WaHostBootstrapper task. Then you have 10 minutes till the vm is restarted. – Ruthy

Answer 2

Simply put, you don't. Doing so is in direct conflict to the "stateless" nature of Windows Azure PaaS Cloud Services. If an instance of a role needs to be moved, it will always revert to its originally deployed state, nullifying any changes you've made. And role instances may get moved at any time. So any attempt to RDP in and make changes will cause your significant pain.

If you really need this type of dynamic deployment, you can create a start-up script that pulls content files from an external store (such as Windows Azure Blob Storage) and pulls them into the role instance prior to start.

The worker itself is just a long running console program with an initial process started by a call from the Windows Azure Agent process in your guest VM to the "OnStart" method of a role instance.

Publicity

Just to add to this, the same statelessness Brent is talking about goes for Web Roles as well. What you are doing to update the web roles may work for your development or testing, but you should never do that for production systems. The changes won't be maintained across role updates, OS patches, etc. Everything Brent indicated. – Sebiferous

Thanks for the heads up, But I wont be doing any such changes on the production server. Since am still in development stage, its quite a pain to re deploy everything just to see some minor changes, hence was looking for some work arounds. I am hoping Kwill's answer will do the trick. – Strick

is there some need here that the local emulator isn't fulfilling? – Publicity