Using Visual Studio create a new C# Console application.
When the standard console application is created from the template, it will not have a reference to the storage client library. We will add it using the Package Manager (NuGet).
Right-click on the project, and select ‘Manage NuGet Packages’ from the context menu.
This will load up the Package Manager UI. Select the ‘Online‘ tab from the Package Manager dialog, and search for ‘Azure Storage’. As of the time of this writing version 2.0.5.1 was available. Select the Windows Azure Storage package and click ‘Install‘.
If you prefer to manage your packages via the Package Manager Console, you can also type
Install-Package WindowsAzure.Storage
to achieve the same result. The Package Manager will add the references needed by the storage client library. Some of these references won’t be utilized when just working with BLOB storage. Below you can see that several assembly references were added, but specifically the Microsoft.WindowsAzure.Configuration
andMicrosoft.WindowsAzure.Storage
assemblies are what we will be working with in this example.
Open up the
program.cs
file and add the following using
statements:
Then add this code to the Main method:
Modify the code to add the storage account name for the
accountName
variable and the storage account access key from when you created the account in the portal for the accountKey
variable. Also, substitute the file name used with the OpenRead
method with a file that you wish to upload. I’d suggest an image or something small for this example. For real applications, you will want to have the account name and key in a configuration file, or passed in so that you are not hard-coding these values.
The account name and key values are used to create a
StorageCredential
instance, which is then used to create an instance of the CloudStorageAccount
object. The CloudStorageAccount
object represents a storage account that you will be accessing. From this object you can obtain references to BLOBs, tables and queues within the storage account. Note that when we create the instance of the CloudStorageAccount
, we specify ‘true’ for the useHttps
constructor argument. This will cause all of our operation calls to our storage account to be encrypted with SSL. Because all wire-level communications are therefore encrypted, and all requests are signed using the credentials provided in the StorageCredential object, we can have some confidence that our operations are secure from prying eyes.
Since we are using BLOB storage, we then create an instance of a
CloudBlobClient
object to provide the client interface that is needed to work with BLOBs. Using the CloudBlobClient
object we then get a reference to a container. A container is much like a base directory off the root of a hard drive. In this case, the container we are getting a reference to is named “samples”. On the next line, we call CreateIfNotExists
which will actually cause the client library to call out to the public REST endpoint in Windows Azure to check if the container exists and, if not, will create the container. This provides us a location to upload our file to.
The last portion of the code gets a reference to a block BLOB within the container we created. This file doesn’t exist yet, we are just creating a reference to it as a
CloudBlockBlob
object. We will then use this to upload the file by providing a file stream of our file to the UploadFromStream
method. The client library will then send up the file, creating the file in our Azure storage account. Note that many of the client library methods support the asynchronous programming pattern using Begin/End versions. For example, to asynchronously start an upload you can call BeginUploadFromStream.
The client library may make more than one call to the REST API to upload the file if it is fairly large. You can control the size of file that is sent up as a single operation by setting the
SingleBlobUploadThresholdInBytes
property. This defaults to 32 MB and can be set as high at 64 MB. Anything over that 64 MB mark will be automatically broken into smaller blocks and uploaded. If a file does get broken down by the client library for upload, it will use a single thread by default to perform the upload. You can set theParallelOperationThreadCount
property to indicate how many threads you would like the client library to use to concurrently upload your file. Just be sure to be careful that if you are asynchronously uploading a lot of files and setting theParallelOperationThreadCount
option fairly high, you may see some ‘bottlenecking’ and slow throughput
No comments:
Post a Comment