Connection string (webjobs) in test deployment slot

0
votes

It seems I can't get any control over the connection string my webjob is using. There are probably more questions involved, but I don't know what exactly is causing my issues.

I have a production environment, and a test deployment slot. There are 3 webjobs running on both. All web jobs and my website have a connection string defined in their app.config resp. web.config.

    <add name="SQLAZURECONNSTR_MyConnectionStringName" connectionString="Server=xxx;Database=MyTestDatabase;User ID=xxx;Password=xxx;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;MultipleActiveResultSets=true" providerName="System.Data.SqlClient" />

When I do a swap, the used connection string is swapped as well, I've read that's as designed. Now, I want my test environment to always point to my test DB, so after the swap, I try to override my connection string in the azure portal, but that has no effect. Test environment is still using Production DB.

Only after I publish my local version (with conn. string pointing to TestDB) to staging, I see my test-website is pointing to testDB again (why is it not overridden by Azure Portal connection string setting?)

However, last night, I did a swap, set my connection strings (in app.config and web.config) to TestDB, publish to testEnvironment, also published webjobs to testEnvironment. They still worked with productionDB... I login to my azure portal -> Test deployment slot. It shows no web jobs (while I'm positive they are running).

Note: I have a lot of problems with publishing since I use webjobs. So there is a probability that something went wrong with publishing as well.

A lot of text, mostly to try to elaborate my confusion. It might boil down to a few questions:

  • In what cases does the azure portal connection string setting override the connection strings in web/app.config?

  • Why do my webjobs show inconsistent behavior in terms of conn. string?

  • How can I get rid of this manual webjob publish nonsense once and for all, I'm using settings.job way to publish schedule webjobs, that solved a few, but not all of my problemes.

1
azureconnection-stringpublishazure-webjobsazureportal

1 Answers

2
votes

The following blog post should answer your deployment slots questions.

In short:

  • The portal connection strings always overrides the web app or webjob web.config/app.config connection strings.
  • The portal can sometime show invalid data regarding webjobs (Azure portal bug), one credible way to see this data is by going to https://{sitename}.scm.azurewebsites.net/api/webjobs
  • Just need to make sure the binaries are deployed to the right location (`d:\home\site\wwwroot\app_data\jobs\{job_type}\{job_name}.