Preparing for Application and Service Deployment-Differences Between the Storage Emulator and Window

http://msdn.microsoft.com/en-us/library/gg433135.aspx

The Windows Azure storage emulator acts as a local emulator for Windows Azure storage services, so that you can build and test your application before you deploy it as a hosted service to the Windows Azure. Some differences exist between using the storage emulator and using Windows Azure storage services.

General Differences

The following general differences apply to storage services:

• The storage emulator supports only a single fixed account and a well-known authentication key. This account and key are the only credentials permitted for use with the local storage services. They are:
  
  
  Account name: devstoreaccount1
  Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
  

  Important
  The authentication key supported by the storage emulator is intended only for testing the functionality of your client authentication code. It does not serve any security purpose. You cannot use your production storage account and key with the storage emulator. You should not use the local storage account with production data.

• The storage emulator is not a scalable storage service and will not support a large number of concurrent clients.
  
  
• The URI scheme supported by the storage emulator differs from the URI scheme supported by the cloud storage services. The development URI scheme specifies the account name as part of the hierarchical path of the URI, rather than as part of the domain name. This difference is due to the fact that domain name resolution is available in the cloud but not on the local computer. For more information about URI differences in the development and production environments, see Using storage service URIs in Overview of the Windows Azure Storage Emulator.
  
  

Differences for Blob Service

The following differences apply to the Blob service:

• The local Blob service only supports blob sizes up to 2 GB.
  
  
• If two requests attempt to upload a block to a blob that does not yet exist in the storage emulator, one request will create the blob, and the other may return status code 409 (Conflict), with storage services error code BlobAlreadyExists. This is a known issue.
  
  
• A Put Blob operation may succeed against a blob that exists in the storage emulator and has an active lease, even if the lease ID has not been specified as part of the request. This is a known issue.
  
  

Differences for Table Service

The following differences apply to the Table service:

• Date properties in the Table service in the storage emulator support only the range supported by SQL Server 2005 (For example, they are required to be later than January 1, 1753). All dates before January 1, 1753 are changed to this value. The precision of dates is limited to the precision of SQL Server 2005, meaning that dates are precise to 1/300th of a second.
  
  
• The storage emulator supports partition key and row key property values of less than 900 bytes. The total size of the account name, table name, and key property names together cannot exceed 900 bytes.
  
  
• The total size of a row in a table in the storage emulator is limited to less than 1 MB.
  
  
• The storage emulator does not validate that the size of a batch in an entity group transaction is less than 4 MB. Batches are limited to 4 MB in Windows Azure, so you must ensure that a batch does not exceed this size before transitioning to the Windows Azure storage services.
  
  
• In the storage emulator, querying on a property that does not exist in the table returns an error. Such a query does not return an error in the cloud.
  
  
• In the storage emulator, properties of data type Edm.Guid or Edm.Binary support only the Equal (eq) and NotEqual (ne) comparison operators in query filter strings.
  
  

Differences for Windows Azure Drives

The following differences apply to the Windows Azure drives:

• When mounting a Windows Azure drive from the Windows Azure compute emulator, the drive must be backed by a page blob created in the storage emulator. It is not possible to mount a drive from the compute emulator that is backed by a page blob in Windows Azure. This behavior differs from that of the other Windows Azure storage services, which can be accessed in the cloud from code that is running in the compute emulator.
  
  
• When creating a new Windows Azure drive from the compute emulator, be sure to specify the credentials for the local storage account.