Oran Dennison has been dissecting the new Live Framework Tools for Microsoft Visual Studio (“VS tools”) and raised a few questions about how the VS tools are uploading Live Mesh application files into the cloud.
“Why does VS upload files to the cloud individually instead of as one zip file?”
VS uploads individual files to the cloud because that’s what the cloud service APIs for application upload require. When you manually upload an application zip file to the http://lx.azure.microsoft.com developer portal, the developer portal internally unzips the files and uploads them to the actual cloud storage. The developer portal is just a UI frontend to the actual cloud services backend. VS tools talk to the cloud services backend.
“What if Visual Studio dies before uploading all the application files? It seems like updating an app by manually uploading a zip file is a safer, slightly more atomic operation.”
First of all, the goal of tools is to eliminate manual repetitive tasks. Uploading an app to the cloud certainly qualifies as manual and tedious and something that is going to need to be done a lot (every time you hit F5 to run the app).
If VS dies (or more likely, you lose your network connection) before uploading all the application files, the worst thing that will happen is that you will be left with a debug application resource feed that is incomplete. VS doesn’t upload files into your existing installed mesh application, it creates a separate debug application resource to upload into and debug from. This helps ensure that the bits you’re debugging are the bits that VS put there that match your local debug symbols, without any interference from automatic application updates caused by changes elsewhere in the system.
“Once real production apps are being upgraded, something more robust would be nice”
Visual Studio never debugs or uploads applications into a public, production environment. You’re always operating on an application that is tagged as in “development” mode in the cloud. When you’re finished with development (and testing) you go to the developer portal and throw a big switch to push your application into production mode, accessible to the general public.
I believe (not sure here) that pushing the app into production will only expose one version of the application’s resource feed. If that is the case, then you should be able to continue development of that app in VS because VS always uploads and debugs from a separate (private / nonpublished) debug application resource feed.
“When my app is sync’d to my local machine, does it download the zip file or the individual files of the app?”
The files in your application are stored in the cloud as entries in an application resource feed. When the contents of your application feed needs to be sync’d to a particular device, the sync granularity is at the level of individual files. The Live Mesh client does not download the zip file you uploaded to the cloud because (as far as I know) that zip file no longer exists anywhere.
A lot of what you see in this CTP release of the tools will change significantly before we release. For example, the manual process of uploading the app to the cloud to get the app self link to paste into VS will definitely be going away as soon as the cloud implements and exposes the app creation and provisioning services needed by tools.
Our goal for the Live Framework Tools for Visual Studio is to make developing Live Mesh enabled applications as seamless as developing a desktop app. You create a project, make some edits and F5 to run the app, stop at some source code breakpoints, evaluate some variables, close the app, edit and F5 to run again. Whether the app is in the cloud or on the local machine will be a footnote to the development cycle you’re used to, not a radical departure.