Skip to main content

Windows Azure Storage Emulator and testing servers

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:
Account Name: devstoreaccount1
Account Key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
Basically these are universal credentials that can be used on all the Windows Azure Emulator instances. The purpose of this is only for development and testing.
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:
When we are using a real blob, our path would be similar to this:
There is a little difference of the path. This small difference can make a big different when we want to start to isolate our testing machine 100%.
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:
This is the path to all your content.
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.


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.