3

While developing an Azure WebJob I encounter the exception

Failed to validate Microsoft Azure WebJobs SDK Storage account. The Microsoft Azure Storage Emulator is not supported, please use a Microsoft Azure Storage account hosted in Microsoft Azure.'

This seems to be fairly common and the solution is usually to update the connection string to a specific value. However, in my case I already have this specific connection string.

Furthermore, I have two WebJobs in the same solution: I'm using exactly the same connection strings in both cases, and the other WebJob connects without any problems.

In the App.config I have

<connectionStrings>
    <add name="AzureWebJobsDashboard" connectionString="DefaultEndpointsProtocol=https;AccountName= ... ;AccountKey= ... " />
    <add name="AzureWebJobsStorage" connectionString="DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;TableEndpoint=http://127.0.0.1:10002/devstoreaccount1;QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;" />
</connectionStrings>

The same connection string appears under appSettings:

<appSettings>
    <add key="StorageConnectionString" value="DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;TableEndpoint=http://127.0.0.1:10002/devstoreaccount1;QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;" />
    <!--<add key="StorageConnectionString" value="UseDevelopmentStorage=true" />-->
</appSettings>

I've found that entering UseDevelopmentStorage=true makes no difference.

I've also tried manually declaring these in the static void Main:

var config = new JobHostConfiguration {
                                          JobActivator = new WebJobActivator(kernel)
                                      };
config.DashboardConnectionString = "DefaultEndpointsProtocol=https;AccountName= ... ;AccountKey= ... ";
config.StorageConnectionString = "DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;TableEndpoint=http://127.0.0.1:10002/devstoreaccount1;QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;";

and when I do this, the exception is then thrown on

config.StorageConnectionString = ...

I'm running v5.2 of the Azure Storage Emulator - and it is running. And like I said, the other WebJob is able to connect and run without any problems, and they both have identical App.config files.

I've also commented-out all other code in the WebJob so all it should be doing is attempting to start and connect to the queue.

And lastly, even if I declare the connection string for the live storage I still get the same exception.

Why? What is wrong with these connection details?

awj
  • 7,482
  • 10
  • 66
  • 120
  • What version of Microsoft.Azure.WebJobs are you using in each project? I do recall that in v1.x of the Microsoft.Azure.WebJobs package, using the emulator for the AzureWebJobsDashboard or AzureWebJobsStorage was not supported (I do not remember which was not supported). It wasn't until >= v2.x that you could use the emulator for those keys. – Rob Reagan Oct 16 '17 at 12:23
  • If you put this in an answer rather than a comment then you'll get the full points available. – awj Oct 16 '17 at 12:59

1 Answers1

10

Check to see if you are running Microsoft.Azure.WebJobs v1.x or earlier. I do recall that in v1.x of the Microsoft.Azure.WebJobs package, using the emulator for the AzureWebJobsDashboard or AzureWebJobsStorage was not supported (I do not remember which was not supported). It wasn't until >= v2.x that you could use the emulator for those keys.

Rob Reagan
  • 7,313
  • 3
  • 20
  • 49
  • 4
    Brilliant, that's it. I assumed that if I used the VS 2017 WebJob project template I would be up-to-date, but clearly not. It was referencing v1.2 out of the box. Updating to v2 solves the problem. – awj Oct 16 '17 at 13:01