I have built one startup task for Azure application contain exe file(running periodically with some time interval) and now i would like to make it autoupdating at every week as i have asked before here
However i'll do some logic of replacing that file through that exe(startup task) then also it is not going to take any effect of new file. I have concluded that new startup task will take effect only if we upgrade/created that azure project with new file. (Correct me if i understood something wrong)
So is there any way to do my logic works by rebooting instance (by exe/startuptask) ?
I think it will also take original file(added in startuptask at the time of upgrading/creating application) instead of new file!
Is it possible anyway?
After I studied your problem i can propose a very simple solution as below which I have done before for a Tomcat/Java Sample:
Prepare your EXE to Reboot the VM along with your original code:
- In your EXE, create a method to look for specific XML file on Azure storage at certain interval, also add retry logic to access XML
- Parse XML for specific value and if certain value is set reboot the Machine
- Package your EXE in ZIP format and place at your Azure Storage
- Be sure to place the XML on Cloud and set the reboot = false value
What to do in Startup Task:
- Create a startup task and download the ZIP from Azure Storage which contains your EXE
- After the download, unzip the file and place the EXE to specific folder
- launch the EXE
What to do when you want to update the EXE:
- Update your EXE, package into ZIP and place at same place at Azure Storage with same name
- Update your XML to enable Reboot
How update will occur:
- The EXE will look for XML after certain internal as designed
- Once it sees Reboot is set, it will reboot the VM
- After the reboot, the Startup task will be launched and your new EXE will be downloaded to Azure VM and will be updated. Be sure that download and update is done at same folder.
Take a look at Startup tak in the sample below which use similar method:
http://tomcatazure.codeplex.com/
This is a very unreliable solution. If an Azure instance crashes or is taken down for updates you will have a new instance started from the original service package. All the state of the modified instance will be lost.
A much more reliable way would be to have the volatile executable stored somewhere like Azure Blob storage. You upload a new version to the blob storage and the role somehow sees that (either by polling the storage or by some user-invoked operation - doesn't matter), downloads the new version and replaces the existing version with the new one.
This way if your role crashes it will reliably fetch the newest version from the persistent storage on startup.