Connection string name "Storage" didn't work

[vijayrkn]

From @TsuyoshiUshio on August 16, 2017 4:44

Overview

When I write a Queue Trigger with connection string name "Storage" doesn't work. However if I change the name to like "fooStorage" it works. Does it any naming rule about it?

Step to Reproduce

1. Create a Queue Trigger on your VS Enterprise 2017 preview 15.3.0 Preview 7.0

using System;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host;

namespace QueueLocalTesting
{
    public static class QueueLocal
    {
        [FunctionName("QueueLocal")]
        public static void Run([QueueTrigger("%ProcessingQueueName%", Connection = "fooStorage")]string myQueueItem, TraceWriter log)
        {
            log.Info($"C# Queue trigger function processed: {myQueueItem}");
        }
    }
}

2. On your Azure, create an Azure Functions then configure connection string on Application Settings.

App Settings

ProcessingQueueName  YOUR_QUEUE_NAME

Connection Strings

fooStorage    YOUR_STORAGE_CONNECTION_STRING Custom
Storage          YOUR_STORAGE_CONNECTION_STRING Custom

NOTE: YOUR_STORAGE_CONNECTION_STRING is the same.

3. Queue something the function is triggered

4. Change the connection "fooStorage" into "Storage" It doesn't work.

Expected result

It should be the same behavior. Or If "Storage" is already taken by the system, please let us know.

Actual Result

Only "Storage" doesn't work. e.g. "fooStorage" works.

Notes

When I tried it via AppSettings using the name "Storage", the behavior is the same.

Copied from original issue: Azure/azure-functions-vs-build-sdk#95

[vijayrkn]

From @mathewc on August 16, 2017 5:16

The logic in the core WebJobs SDK that we use to resolve connection strings is here: https://github.com/Azure/azure-webjobs-sdk/blob/dev/src/Microsoft.Azure.WebJobs.Host/AmbientConnectionStringProvider.cs#L34

Try adding your connection strings as actual app settings, not connection strings. If you add an app setting named "Storage" it should work. The common pattern is for connection strings is that they are prefixed with "AzureWebJobs", e.g. "AzureWebJobsStorage". However as you can see from the code I linked to, we try that prefix first, then try w/o prefix.

[vijayrkn]

From @TsuyoshiUshio on August 16, 2017 5:45

I read the code. I understand why it happens. Azure Function already use "AzureWebJobsStorage" App Settings as a default. When I set the Storage, "AzureWebJobsStorage" hit first. Which means, it point the other storage account. The queue trigger works fine, however, it observes different storage account. So we need to avoid "Dashboard" and "Storage" at least.

[vijayrkn]

From @TsuyoshiUshio on August 16, 2017 5:58

In addition, "ServiceBus" should be avoided. :) https://github.com/Azure/azure-webjobs-sdk/blob/663a508e8a851629c26a51e7de3af36629dfd120/src/Microsoft.Azure.WebJobs.Host/ConnectionStringNames.cs

[vijayrkn]

From @peterhuene on August 16, 2017 6:19

I'm curious as to why AmbientConnectionStringProvider checks the prefix for all requested connection strings. If these three constants are the extent of what the host uses for connection strings, why not prefix the string constants themselves and avoid potentially conflicting with user-defined connection string and setting names? I'm sure there's a good reason for it being the way it is, though.

[vijayrkn]

From @peterhuene on August 16, 2017 6:28

Also, this should probably be an issue (if it is one) on the azure-webjobs-sdk repo. It's runtime behavior and not build.

[kumarz]

I am running into a similar situation for .Net framework 4.6.2. I am getting the following error message in spite of having the value in app.config.