In Windows Azure, what file should I put storage information in for ASP.NET MVC?

Question

I'm toying with Windows Azure creating an ASP.NET MVC project, I've checked the WAPTK (Windows Azure Platform Training Kit), Google, and here for answers to my question, but I couldn't find the answer. In an ASP.NET MVC project, in what file do I create containers for cloud storage? (In the WAPTK, there's a hands-on lab that uses webforms and puts storage containers in the _Default partial class.)

Answer 1

In an ASP.NET MVC project, in what file do I create containers for cloud storage? (In the WAPTK, there's a hands-on lab that uses webforms and puts storage containers in the _Default partial class.)

Generally I'd recommend you set up the container access (including the create) in some nicely encapsulated class - preferably hiding behind an interface for easy testability.

I'd recommend:

• put this class and it's interface in a class library (not in your ASP.Net project)
• put the config details in the csdef/cscfg files
• if you only plan to use a fixed list of containers, then either:
  • create these ahead of installing your app - e.g. from a simple command line app
  • or create these from a call in the init of Global.asax
• if you plan to dynamically create containers (e.g. for different users or actions) then create these from Controller/Service code as is required - e.g. when a user signs up or when an action is first performed.
• if actions might occur several times and you really don't know if the container will be there or not, then find some way (e.g. an in-memory hashtable or in-sql persistent table) to help ensure that you don't need to continually call CreateIfNotExist - remember that each call to CreateIfNotExist will slow your app down and cost you money.
• for "normal" access operations like read/write/delete, these will typically be from Controller code - or from Service code sitting behind a Controller

If in doubt, think of it a bit like "how would I partition up my logic if I was creating folders on a local disk - or on a shared network drive"

Hope that helps a bit.

Stuart

Answer 2

You should definitely use blob storage for your files. It's not particularly difficult and as this is a new project there is no need to use Azure Drives.

If you are just using blob storage to serve up images for your site then you can reference them with a normal tag in your html e.g

<img src="http://myaccountname.blob.core.windows.net/containername/filename">

This will only work if the file or container is shared and not secured. This is fine if you are just serving up static content on html pages.

If you want to have secured access to blobs for a secure site then you have to do a couple of things, firstly your website will need to know how to access your blobs.

in your servicedefinition.csdef file you will need to include

<Setting name="StorageAccount" />

and then add

<Setting name="StorageAccount" value="DefaultEndpointsProtocol=https;
AccountName=[youraccountname];AccountKey=[youraccountkey]" />

to your serviceconfiguration.csfg file.

Then you can use the windows azure SDK to access that account from within your web role. Starting with

Dim Account As CloudStorageAccount = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("StorageAccount"))
Dim blobClient As CloudBlobClient = Account.CreateCloudBlobClient

From there you can

• Read/write to blobs
• delete blobs
• list blobs
• create time limited urls using shared access signatures.

There is a great resource here from Steve Marx. Which although it is about accessing blob storage from silverlight which you are not using does give you lots of information in one place.

Your question wasn't very specific but this should give you some idea where to start.

@Faester is correct you will probably need some resource either table storage or SQL Azure to store references to these files.

Answer 3

I am not sure if I understand you correctly, but generally speaking files and Azure doesn't fit together well. All changes stored at the local file system are volatile and only guaranteed to live as long as the current Azure instance. You can however create a blob and mount it as a local drive, which makes the data persistent. This approach has some limitations, since it will allow one azure instance writing and maximum 8 readers.

So instead you should probably use blobs rather than files. The problem of knowing which blob to access would then be solved by using Azure table storage to index the blobs.

I recently went to a presentation where the presenter had investigated quite a bit about Azure table storage and his findings was that limiting partition keys to groups of 100-1000 elements would give the best performance. (Partition keys are used internally by azure to determine which data to group.)