azure-functions-core-tools: better error message if the CLI sees nested values in local.settings.json
Hey guys,
I’m still having issues debugging locally with the local.settings.json and AzureWebJobsStorage - I’m not sure if that one is the real issue or the error is a different one but the exception is not right.
I’m running VS 2017 Enterprise Edition version 15.3.2 I have the last versions of Azure Functions CLI (and tried with the 2 latest: 1.0.11075.0, 1.0.11015.0)
This is how my local.setting.json looks like
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsDashboard": "<changed by alemag>",
"AzureWebJobsStorage": "<changed by alemag>",
"commservicetopic": "<changed by alemag>",
"EmailProvider": "<changed by alemag>",
"SparkPostClientId": "<changed by alemag>",
"SMSProvider": "<changed by alemag>",
"ClickSendClientId": "<changed by alemag>",
"ClickSendKey": "<changed by alemag>",
"PushProvider": "<changed by alemag>",
"MSNotificationHub": {
"HubName": "<changed by alemag>",
"ConnectionString": "<changed by alemag>"
}
}
}
*values are not encrypted
And this is how function.json looks like:
{
"generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
"configurationSource": "attributes",
"bindings": [
{
"type": "serviceBusTrigger",
"connection": "commservicetopic",
"topicName": "commservicetopic",
"subscriptionName": "PushSub",
"accessRights": "listen",
"name": "message"
}
],
"disabled": false,
"scriptFile": "..\\bin\\CommService.dll",
"entryPoint": "CommService.MobilePush.Run"
}
Things that I tried:
- remove the Azure.Functions folder from C:\User<username>\AppData\Local.…
- run it from the command line as well as VS… no luck.
- put the local.setting.json in every possible debug/release/bin folder nothing.
- adding an applicationsettings.json and the Azure-Cli detected the 2 files and warned that application settings file will be ignored and local.setting.json was going to be used.
The function is triggered by a Service Bus (commservicetopic from local.settings.json key-values pairs).
Function is working perfectly fine in Azure Cloud with same endpoints for AzureWebJobsStorage and ServiceBus.
I was able to debug the function back in VS 2017 Preview 15.3.
Thanks!
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 20 (5 by maintainers)
The solution was to right-click on local.settings.json, go to properties, change “Copy to Output directory” from “Do not copy” to “Copy always”. Now the CLI picks up the settings when running from within Visual Studio 2017.
Got it! If you use settings with more than one level in local.settings.json, it ignores the whole “Values” section and gives you this error. Ex: This is OK:
But this generates an error:
This needs to fail with a better error message. Why would anyone expect valid, legal JSON to cause problems? If you aren’t going to support nested JSON, then return an warning saying as much, highlighting which properties are in violation. Key-values that are the expected string/string should still just work fine.
@alemag1986 sorry for the delay.
This is because of this value
Values
collection is expected to be aDictionary<string, string>
and it’s failing to parse it and returning an empty dictionary. I think parsing it as aJObject
and displaying an error for any non-string values would be more correct here.I know it’s a bit confusing with the .NET Core appsettings.json, but this file
local.settings.json
is meant to just be a local equivalent to the Azure App Settings which are just key-value pairs.You can test that locally by running
func settings list
in that directory. It should print empty values and connection strings. removing thatMSNotificationHub
property should getfunc settings list
to work.Since settings.json does not support nested JSON, can you please describe the recommended alternative to storing nested JSON in configuration?
for those who are not behind VS, the CopyToPublishDirectory is what did the trick in my environment:
Azure Functions Core Tools (2.0.1-beta.31) Function Runtime Version: 2.0.11888.0
with the following local.settings.json
@ahmelsayed I think this really needs some better warning on failure - I’ve just spent a lot of time trying to work out why my application settings weren’t being read, and I don’t think it’s unreasonable to assume that valid JSON, in the format recommended elsewhere by Microsoft for .NET Core app settings, silently continues without loading any settings.
Also found out that arrays are not supported