When you start to work with Windows Azure Storage Services like blobs or table you will need to specify an account name and a secret key. Working with the Windows Azure Storage Emulator you ask yourself what credentials I should use.
The good part of the story is that Microsoft offers us a default account name and key that can be used to access the storage. This can be used with success whey you want to use the local storage emulator:
When you are staring development an application you should know that the path to the resources is a little bit different between the Windows Azure and your local machine. Your local resources are accessed using a path in the following format:
The first think that we can do is to set the connection string to “UseDevelopmentStorage=true”. This will solve your problem if you don’t have hardcoded file paths. Otherwise you should define different file path to blob storage if you are using an emulator or the storage from cloud.
If you are asking yourself – Where is the content of the blob stored where I’m using emulator? – the response would be in the following path:
Another solution for your problem is to map all your content from the blob on your servers IIS and play a little with the DNS. In this way you could “emulate” the real storage emulator without the need to have the Windows Azure Emulator installed on the server.
From my perspective the best solution to create a server where you test your application is to isolate all requests that use Windows Azure Storage and group them in a component. When you would test the application you would use a mock component that would use directories and files.
In this way your testing machine would be isolated 100%. Also testing that access to Windows Azure Storage works is an integration test of a component/resource and this is not your main goal.
The good part of the story is that Microsoft offers us a default account name and key that can be used to access the storage. This can be used with success whey you want to use the local storage emulator:
Account Name: devstoreaccount1
Account Key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
When you are staring development an application you should know that the path to the resources is a little bit different between the Windows Azure and your local machine. Your local resources are accessed using a path in the following format:
http(s)://127.0.0.1:10000/myAccount/myContainer/myContent.txt
http(s)//myAccount.blob.core.windows.net/myConainer/myContent.txt
The first think that we can do is to set the connection string to “UseDevelopmentStorage=true”. This will solve your problem if you don’t have hardcoded file paths. Otherwise you should define different file path to blob storage if you are using an emulator or the storage from cloud.
If you are asking yourself – Where is the content of the blob stored where I’m using emulator? – the response would be in the following path:
C:\Users\myAccount\AppData\Local\dftmp\s0\...
Another solution for your problem is to map all your content from the blob on your servers IIS and play a little with the DNS. In this way you could “emulate” the real storage emulator without the need to have the Windows Azure Emulator installed on the server.
From my perspective the best solution to create a server where you test your application is to isolate all requests that use Windows Azure Storage and group them in a component. When you would test the application you would use a mock component that would use directories and files.
In this way your testing machine would be isolated 100%. Also testing that access to Windows Azure Storage works is an integration test of a component/resource and this is not your main goal.
Comments
Post a Comment