I created a new Azure WebJob project in Visual Studio 2015 using .NET Framework 4.6.
In the app.config, I set three connection strings:
AzureWebJobsDashboard
AzureWebJobsStorage
MyDatabaseConnectionString
The AzureWebJobsDashboard and AzureWebJobsStorage connection strings are identical and they're both pointing to my storage account. I'm including one of the connection strings -- since they're both identical, except the "name".
<add name="AzureWebJobsDashboard" connectionString="DefaultEndpointsProtocol=https;AccountName=mystorageaccountname;AccountKey=thisIsTheLongPrimaryKeyICopiedFromAzurePortalForMyStorageAccount" />
Everything looks right to me but I'm getting the following error:
The configuration is not properly set for the Microsoft Azure WebJobs
Dashboard. In your Microsoft Azure Website configuration you must set
a connection string named AzureWebJobsDashboard by using the following
format DefaultEndpointsProtocol=https;AccountName=NAME;AccountKey=KEY
pointing to the Microsoft Azure Storage account where the Microsoft
Azure WebJobs Runtime logs are stored.
By the way, I know the app.config is being read by the web job because my code is able to connect to my database and update some records.
Any idea what I'm doing wrong?
You need to set the AzureWebJobsDashboard connection string in the portal in your Web App Application Settings blade (steps to do that here). The Dashboard runs as a separate site extension and doesn't have access to app.config. Add the connection string to the connection strings section on the settings blade.
You can add your other connection strings there as well (e.g. AzureWebJobsStorage) rather than storing in app.config if you wish for security/consistency, however the WebJob can read AzureWebJobsStorage from app.config.
The change needs to be done in App Services settings in Azure Portal
For that
Open the Azure (Management) Portal at https://portal.azure.com
Goto Home > App Services
Select the App service that is hosting your WebJob
Goto Settings > Choose Application settings
Scroll down to Connection strings
Add a new connection string with Name as 'AzureWebJobsDashboard' and Value as . Choose Type as 'Custom'
Press Save Button ( at the Page Top)
All done! Check your Webjobs Dashboard - the Warning and Error message at top should be gone now.
I was having this problem too.
My storageaccount kind is StorageV2 (general purpose V2)
I had both AzureWebJobsDashboard and AzureWebJobsStorage correctly set in the App Service Configuration.
But, the storage account had a Minimum TLS version set to 1.2
I found that changing this to 1.0 was needed for the WebJobs Dashboard to display correctly and for the WebJobs to run ok.
Right now (version of Web Job Tools is 15.0.31201.0) no necessary to configure any connection strings from azure portal, enough to set it in app.config file of web job
Related
I have created Azure App configuration and sets Key and value pairs. I have also created a HTTP Azure function via VS 2019 and write below code.
using Microsoft.Extensions.Configuration;
using Azure.Identity;
var config = new ConfigurationBuilder().AddAzureAppConfiguration(options =>
{
options.Connect(new Uri("https://xxx-xxx-azf-global-parameters.azconfig.io"),
new ManagedIdentityCredential());
}).Build();
string str = config["AzfApp:Cloud"].ToString();
log.LogInformation("AzfApp:Cloud:" + config["AzfApp:Cloud"].ToString());
Enable System assigned Identity of Azure Function. The identity I am using via ManagedIdentityCredential is assigned to both the Azure App Configuration Data Reader and Azure App Configuration Data Owner roles. But above my code is not working Azure portal. I have capture the error via log information.
Error message :Retry failed after 3 tries. (No such host is known.) (No such host is known.) (No such host is known.)Source=Azure.CoreStackTrace:at Azure.Core.Pipeline.RetryPolicy.
Please help on this how do I resolve the issue.
I test in my site with your code and it works very well.
Go to azure app configuration and double check that you have assign Azure App Configuration Data Reader to the function's Identity.
And the output screenshot is as below:
I have a web form developed in ASP.NET and C#. I am storing the connection string to a database in the web.config file like this:
<connectionStrings configSource="MySecrets.config" />
This points to a local file in the same directory as the solution. Debugging locally works, however it is not advisable to commit this file to source control to avoid exposing these secrets.
This article mentions that it is possible to store connection strings on Azure - in the Configurations section of an App Service. The article also says that it's possible to retrieve the connection strings in the code by doing:
dbConn = System.Configuration.ConfigurationManager.AppSettings("myConnStringName")
The article also mentions that "if the application setting(s) happen to already exist in your web.config file, Windows Azure Web Sites will automatically override them at runtime using the values associated with your website. Connection strings work in a similar fashion.
(This assumes that your connection strings are explicit in the web.config file, and if committed to source control, they would be exposed.)
However, in my code, I already have a line with:
dbConn = WebConfigurationManager.ConnectionStrings["myConnStringName"].ConnectionString
Questions:
1) How am I supposed to reconcile these two lines without declaring the same variable (dbConn) twice?
2) How can I not commit MySecrets.config to source control, but at the same time use it when I debug my app locally, while using the connection string stored on Azure when working with the published app?
I created an Azure function app locally in Visual Studio 2017(Not Azure portal) by following the steps at the following URL.
https://blogs.msdn.microsoft.com/appserviceteam/2017/03/16/publishing-a-net-class-library-as-a-function-app
I followed the steps exactly to create a function that has a “ServiceBusTopicTrigger”. I added the following to my function.json
{
“disabled”: false,
“bindings”: [
{
“name”: “mySbMsg”,
“type”: “serviceBusTrigger”,
“direction”: “in”,
“topicName”: “negotiatedaddcharge_test”,
“subscriptionName”: “clientdispatches”,
“connection”: “servicebusnac”,
“accessRights”: “manage”
}
]
}
My appsenttings.json has the following
{
“IsEncrypted”: true,
“Values”: {
“servicebusnac”: “Endpoint=MyCompanyEndPointPlaceHolder”
}
}
When I run the function in Visual Studio I keep getting an error message “Microsoft.Azure.WebJobs.ServiceBus: Microsoft Azure WebJobs SDK ServiceBus connection string ‘AzureWebJobsservicebusnac’ is missing or empty.”
Just for the heck of it I added another entry to the values collection with the name “AzureWebJobsservicebusnac” but still the same message shows up. Is there something that I am doing wrong?
Also how do you unit test this function? I cannot Access any function in the csx file in my unit test project.
Thanks.
Edited:
I added information to make it clear that I am creating the function in Visual Studio rather than the Azure portal.
Function App will search for your Service Bus connection strings in Environment variables. You can set those from Azure portal:
Go to your Function App.
Select Platform features tab above the editor.
Click Application settings.
Under App settings section add an entry with connection name and string.
The appsettings.json file is used to support local development only, and settings defined there are not published to Azure.
The solution is simple; I actually ran into this myself and it had me completely stumped for a while.
In your appsettings.json, change "IsEncrypted" from true to false. This should fix the issue you're seeing.
The error messages are less than ideal for this scenario; the Azure Functions team already has a bugfix in for it.
Hope this helps anyone who runs into this issue. (I swear, it was a week before I figured this out, and not without help.)
I am adding a webjob project to a website project. Webjob project requires AzureWebJobsStorage and AzureWebJobsDashboard connection strings in the environment when deployed to Azure. Is it possible to change the name of these connection strings, i.e. MyAzureWebJobsDashboard and MyAzureWebJobsDashboard?
The connection string names themselves are not configurable. They are settable via the JobHostConfiguration.StorageConnectionString and JobHostConfiguration.DashboardConnectionString properties, which would allow you to read and set them however you choose.
However, that won't work for the WebJobs Dashboard itself - it reads the settings directly from the app settings set in the portal and expects these well known names.
After I deployed my mobile service to Azure, calls to the service fails because of this error:
No connection string named 'ApplicationEntities' could be found in the application config file.
The error only occurs on Azure side. When I test the service locally, the connection to the remote database works without a problem.
I separated my solution into several projects:
Web Api
Business Logic
Data Access (contains the DbContext, database first)
Common (contains the entities generated by EF)
As I always do, I copied the connection string generated in my app.config of the DataAccess Assembly into the connectionStrings-Element of my web.config (Web Api project).
<connectionStrings>
<add name="ApplicationEntities" connectionString="<the connection string>" providerName="System.Data.EntityClient" />
</connectionStrings>
In the web deploy settings, I selected the connection string for "ApplicationEntities". I tested it with and without the option "Use this connection string at runtime (update destination web.config). I always get the same error.
Then I got curious and logged the connection strings available via the ConfigurationManager with something like this:
StringBuilder sb = new StringBuilder();
for (int i = 0; i < ConfigurationManager.ConnectionStrings.Count; i++)
{
sb.AppendLine(ConfigurationManager.ConnectionStrings[i].ConnectionString);
}
trace.Info(sb.ToString());
I got two connection strings:
data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true
Data Source=theserver.database.windows.net;Initial Catalog=thedb_db;User ID=theuser;Password=thepassword;Asynchronous Processing=True;TrustServerCertificate=False;
The username and password is strangely different from the username and password stated in the management portal.
Also the EF-Metadata information get lost.
I get this connection strings when testing locally:
data source=.\\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true
metadata=res://*/DataContext.ApplicationEntities.csdl|res://*/DataContext.ApplicationEntities.ssdl|res://*/DataContext.ApplicationEntities.msl;provider=System.Data.SqlClient;provider connection string=\"data source=theserveraddress,1433;initial catalog=thedb_db;persist security info=True;user id=theusername;password=thepassword;MultipleActiveResultSets=True;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;App=EntityFramework\"
I expect to get the same connection strings when running on Azure. Any idea what's going wrong?
Update:
I just went for remote debugging the service (see here). As I opened the downloaded publish-profile in my text editor, I discovered that there is an attribute SQLServerDBConnectionString - containing the connection string that always gets forced when deployed - with the same username and password I'm not aware of that it exists.
I tried to overrwite this connection string but it did not help. That connection remains the active.
Update 2 / May 29th 2014:
Seems that in the meantime the error has been fixed by the azure mobile team. Still running the same code using the database first approach and it's working now. Thanks a lot!
I have myself tried using DB first approach with dot net backend mobile services & ran into same sort of problems as you. Digging around further, following is my observation :
The azure mobile service with dot net backend must use code first approach only. This generates a specialised connection string with metadata (starting with res:)
The name of the connection string has to be the same as it is when you download the default sample todo app I.e. Ms_TableConnectionString.
There is an option in azure websites to select custom SQL provider to help make a custom connection string, this option, however, is not available for dot net backend mobile service in Azure Management portal.
P.s. Posting as answer because I don't have a enough points to comment..
Just wanted to give an update that I have been looking at this for some time and think I for the first time see it too. I don't know what is going on but wanted to let you know that we are indeed looking at it.
Henrik
(I don't have enough points to comment so having to do this as an answer)
Henrik, I have this same problem. If I ftp on to the box I can see that the web.config has the correct connection string but it fails as trying to use the username in the SQLServerDBConnectionString property (OoWUqr****Login). Is it possible you could let me know in what order it is looking for connection strings and where?
And if it can't stop it using the other user is there a way I can permission them for the correct database through mobile services?
Thanks
F