Albert Pascual just posted an interesting article on his experience using Windows Azure. A good read.
One thing that stuck out to me was his point about how if you have a reference to an assembly that in turn references other assemblies that are not being pulled in directly to the web role -- those aren't going to be packaged for deployment.
He even mentions a workaround, which is to directly reference those assemblies and set copy local to true.
This is something we're going to have to investigate and see what we can do, it'd be really helpful to know what dependencies will be missing before trying it out on the Azure Services Developer Portal. Stay tuned.
In the PDC '08 release of the Windows Azure Tools for Microsoft Visual Studio, when you create a new Cloud Service project, that project will contain associations to 0 or 1 web roles and 0 or 1 worker roles. It will also include a single Service Definition and single Service Configuration files.
You'll notice that you can't add additional definition or configuration files to the project either.
This effectively means that you can only have one configuration of your roles and one set of settings.
Some of the scenarios that we want to open up in the future (sorry, no time frame available) are:
We'd need to think this through and provide an end to end solution that meets your needs both on the development side as well as the deployment/management side. That is, the solution would involve more than the tools, it would involve the SDK and the Portal as well.
To that end, if you have feedback that can help us better understand your needs -- please contact me through this blog or on the forum.
That said, there is a workaround that may be of some use to you today -- that is to have more than one Cloud Service project in your solution.
In an existing Cloud Service project where you want to support multiple configurations, right click on your solution in Solution Explorer and Add -> New project... -> Blank Cloud Service. (I am starting with my Simple Table Storage example)
You will now have 2 Cloud Service projects in your solution where the active project will determine which roles and configuration files will be used:
In my sample, the new Cloud Service project is named "SimpleTableSampleCloudStorage". The idea is that the configuration for this Cloud Service will access the Windows Azure Cloud Storage while the existing one access the Development Storage.
You'll notice that there are no roles in the SimpleTableSampleCloudStorage and that it is the startup project. (it's bolded)
I right click on the Roles node and select Add -> Web Role project in Solution...
and then I select the only project listed, SimpleTableSample_WebRole.
Next, I open up the ServiceDefinition.csdef file and add the configuration settings by adding the following to the <WebRole/> node:
I then open up the ServiceConfiguration.cscfg and add the values:
<!--Windows Azure Storage-->
<Setting name="AccountName" value="<insert account name>"/>
<Setting name="AccountSharedKey" value="<insert Access Key>"/>
<Setting name="TableStorageEndpoint" value="http://table.core.windows.net"/>
Now, when I run, since SimpleTableSampleCloudStorage is the startup project, I get the Service Configuration contained in that Cloud Project.
When I make SimpleTableSample the startup project:
and run again, I get the local development storage settings.
Note that the Cloud Service you choose to publish from will affect the Service Definition file that is uploaded to Windows Azure. You also need to double check that you are uploading the Service Configuration file you really want -- they'll look the same and only differ by path.
For an example of how this workaround is used to support different role configurations of the same projects, have a look at the Thumbnails sample in the SDK which contains a Cloud Service project that has both a web role and a worker along with a Cloud Service project that only contains a worker role
Finally, please understand that this is just a workaround that has its pitfalls (it's still pretty hard to manage and doesn't do anything to solve staging and production configurations) but hopefully some of you will find this helpful until we design and implement a better solution for you.
azurejournal just posted an article, Porsche, Live Mesh and Windows Azure which touches on a cool experience that is enabled through Cloud technologies.
That kind of thing is exactly what got me excited about the future of the Cloud in the first place and led me to seek out and join the Cloud Computing Tools team. Can't wait until the next generation of online experiencs becomes a reality.
I've updated the walkthrough I wrote on Deploying a Cloud Service on MSDN based on some feedback. Hopefully it provides more clarity into when you should use the various endpoints (cloudservice.table.core.windows.net versus table.core.windows.net for example) and is a little more concise on some of the terminology.
It's a quick and useful read for when you first try deploying your Cloud Service to Windows Azure, it'll save you a lot of time and pain.
A coworker of mine, Steve Marx, recently posted about creating tables only once due to the performance hit you take when you go to create tables that already exist.
This is a good thing to know and I decided to update my Simple Table Storage sample to follow the pattern that our Personal Web SIte SDK sample uses where on the first request, I create the tables. (same solution as Steve described).
I actually went back and forth a bit because the goal of the Simple Table Storage sample is to introduce folks to using the Windows Azure Table Storage service and thus I wanted to keep it as simple as possible.
I found that the changes are really minor and since even simple sample code has a way of making itself into production, I went ahead and updated the original post and sample code attached to that post.