Windows azure SDK 1.5 is released

Microsoft announced the availability of the Windows azure SDK 1.5 and Windows azure tools for Microsoft Visual Studio 2010. You can download the tools

Here using the Web Platform Installer. All three of these releases are aimed at simplifying development, deployment, and management on the Windows azure platform.

The Windows azure SDK includes des the following new features:

• Re-defined Ted emulator enabling higher fidelity between local & cloud developments & deployments.
• Extends fundamental improvements (Performance of emulator and deployment, Assembly/package validation before deployment)
• Support for uploading Service Certificates in csupload.exe and a new tool csencrypt.exe to help manage Remote Desktop encryption passwords.
• Export enhancements and fixes to Windows azure SDK 1.4.

Also available are several new enhancements in Windows azure tools for Visual Studio for Developing & deploying cloud applications. These enhancements include:

• Add windows azure deployment project from web application project.
• Profile applications running in Windows azure.
• Create ASP. NET mvc3 web roles.
• Manage multiple service deployments in one cloud project.
• Improved validation of Windows azure packages.

Now, it is easier to add a Windows azure deployment project to common web projects like ASP. net MVC, Asp. net web forms or WCF. based on the type of web project that you have, the Project Properties for assemblies are also updated, if the service package
Requires additional assemblies for deployment.

With profiling support in the Windows azure tools you can easily detect performance bottlenecks in your application while it is running in Windows azure.

The tools now support creating ASP. net mvc3 web roles. the new template has des the new Universal ASP. net providers that support SQL azure and it will also make sure that ASP. net MVC assemblies are deployed with your application when you publish to Windows
Azure.

 

If you want to maintain different settings for different deployment environments, the Windows azure tools now support multiple service deployments in the same windows azure project. This is especially useful for managing different windows azure Storage
Connection strings for local debugging and running in the cloud.

Finally the new tools will help you avoid some of the common problems when you deploy your application to Windows azure. if you forget to include a local assembly in your package or you publish with a local azure storage connection string, the tools will
Let you know.

 

Read more about the recent features
Here.

The Windows azure platform training kit has also been updated for the new tools. the Windows azure platform Training Kit has des a comprehensive set of technical content including hands-on labs, presentations, and demos that are designed to help you learn
How to use the Windows azure platform. You can download it
Here.

New windows azure service management API features

Introduction:

We are also excited to announce the release of new Service Management APIs for the following scenarios:

• Rollback an in-progress configuration update or service upgrade
• Ability to invoke multiple "write" operations on an ongoing deployment
• More Descriptive status for role instances
• New API method: Get subtasks

Background:

The
Windows azure service management API enables Windows azure customers to programmatically administer their subscriptions, hosted services, and storage accounts.

Rollback an in-progress configuration update or service upgrade

The
API now exposes a new method-
Rollback update or upgrade-which can be called on an in-progress service update or upgrade. The effects of rolling back an in-progress deployment are as follows:

• Any instances which had already been updated or upgraded to the new version of
  Service Package (*. cspkg) and/or
  Service configuration (*. cscfg) files will be rolled back to the previous version of these files.
• Note that the customer does not need to resupply the previous version of these files-the Windows azure platform will retain these for the duration of the update or upgrade.
  • Any instances, which had not yet been updated or upgraded to the new version, will not be updated or upgraded, since those instances are already running the target version of the service.
  • Typically, such instances are not even restarted by the Windows azure fabric controller as part of the upgrade/update à rollback sequence.

Here are some additional details about the new
Rollback update or upgrade method:

• As abve, rollback can be invoked on an ongoing service configuration Update (triggered
  Change deployment configuration) or service upgrade (triggered
  Upgrade deployment ).
• It only makes sense to call rollback on
  In-Place update or upgrade since
  VIP swap upgrades entail atomically replacing one entire running instance of your service with another.
• Rollback can be applied to upgrades already med in either manual or automatic mode.
• Note that rollback itself can be called in automation or manual mode as well.
  • Rollback can only be called when an update (configuration change) or upgrade is in progress on the deployment, which can be detected by the client via checking whether the value of the "rollbackallowed" flag-as returned
    Get deployment or
    Get hosted service properties-is "true ".
  • In order to invoke the version of these methods which returns the rollbackallowed field, you must use the following version (or greater) in the Request Header: "X-MS-version: 2011-10-01 ". for more information about versioning headers, see
    Service Management versioning.
  • An update or upgrade is considered "in progress" as long as there is at least one instance in the service, which has not yet been updated to the new version.

What's an example of when I might use this?

Suppose you are rolling out a major
In-Place upgrade to your windows azure hosted service. Because your new release is substantially different from the old, you want to control the rate at which the rolout proceeds and so you call
Upgrade deployment in manual mode and begin
Walk upgrade domains. Role instances in the 1st and 2nd upgrade domains appear to come up healthy after being upgraded but, as you're walking the 3rd upgrade domain, some role
Instances in the 1st and 2nd upgrade domains become unresponsive. So you call
Rollback on this upgrade, which will (1) leave untouched the instances which had not yet been upgraded and (2) Roll Back instances which had been upgraded (I. E ., those in the 1st and 2nd upgrade domains as well as any in the 3rd to which the upgrade had
Already been applied) to the previous service package and configuration.

Can't I achieve the same effect by calling update or upgrade on a service-in order to roll that service to the previous version? Iow, what does rollback buy me?

Without
Rollback, if you were in the process of updating or upgrading your service from Version X to Version X + 1 and decided that you wanted to go back to Version X, you first had to update or upgrade all role instances to x + 1 then, after that completed, start
A new update or upgrade to X.
Rollback, it's possible to short-circuit that process (changing the target version from x + 1 to X, in the midst of the upgrade to x + 1 ), which results in less service interruption/Church n. moreover, the Windows azure platform now retains (for the duration
An update or upgrade)
Service Package (*. cspkg) and
Service configuration (*. cscfg) files from the version of the service before the update or upgrade began (x ), which means that the customer does not need to resupply these in the event that he wants to go back to the pre-upgrade version.

Ability to invoke multiple "write" operations on an ongoing deployment

In order to provide customers more flexibility in administering their hosted services, we are relaxing the constraints on when mutable operations can be invoked on deployments. the mutable or write operations are:
Change deployment configuration,
Upgrade deployment,
Update deployment status (used to start or stop a deployment ),
Delete deployment, and
Rollback update or upgrade. In particle, prior to this release, customers were only able to have a single "in-progress" mutable operation on a deployment: once such an operation
Was started, the customer had to wait for that operation to complete before starting another one. That is, the deployment was locked.

With this new
Service management API release, a couple methods (get deployment and
Get hosted service properties) return a new field, which explicitly informs customers as to whether a given deployment is "locked" (unable to have write operations completed MED
On it). Moreover, the period of time during which a lock is held (for a given deployment) is substantially bounded Ced, which enables parallelizing or interrupting certain workflows.

• As with the rollbackallowed field, in order to invoke the version of these API methods which return the locked field, you must use the following version (or greater) in the Request Header: "X-MS-version: 2011-10-01 ".

What's an example of when I might use this?

Suppose you're refreshing an upgrade and there is a bug in the new version of the role code which causes the upgraded role instances to repeatedly crash. this will prevent the upgrade from making progress-because the fabric controller will not move
The next upgrade domain until a sufficient number of instances in the previous one are healthy. this is referred to as a "stuck deployment" and, with this Windows azure release, customers can now get themselves "unstuck. "In particle, in that case, you cowould
Elect to apply a fresh update or upgrade over top of the toxic one.

More Descriptive status for role instances

In order to provide better diagnostic and service health monitoring capabilities, customers can now obtain more descriptive information from
Get deployment about the state of their role instances than was previusly available. Two new fields will be returned (instancestatedetails and instanceerrorcode) and an existing
Field (instancestatus) will contain new values, including: Unknown, creatingvm, startingvm, creatingrole, startingrole, readyrole, role, role, stoppingvm, deletingvm, stoppedvm, wait, unresponsiverole.

• In order to invoke this method, you must use the following version (or greater) in the Request Header: "X-MS-version: 2011-10-01". For more information about versioning headers, see
  Service Management versioning.

New API method: Get subtasks

With this service management API release, we introduce a new method,
Get subscripts, which enables obtaining basic information about a subqueries (the subscriber name, status, and email addresses of the account and service administrators)
As well as the current and Max usage as far as number of storage accounts, hosted services, and cores. That is, with this new method you can programmatically obtain the quotas associated with your submodules.

• In order to invoke this method, you must use the following version (or greater) in the Request Header: "X-MS-version: 2011-10-01". For more information about versioning headers, see
  Service Management versioning.

What's an example of when I might use this?

There are a couple immediate use case for this new method. first, for security compliance purposes, you might have a program which periodically confirms that the configured service administrators for a given submodules are as expected (I. e. that no rogue
Values for accountadmin and serviceadmin have been configured ). secondly, this method provides visibility into a key component of your windows azure bill. namely, the currentcorecount value tells you how many cores all of your hosted services 'deployments
Together are using. The "compute hours" portion of your bill is calculated based on how many cores were used by your services over the billing period.

To read more about all of the Windows azure-related announcements made at build, please read the blog post,

"Just announced @ build: new windows azure toolkit for Windows 8, Windows azure sdks 1.5, geo-replication for Windows azure storage, and more ".