我似乎无法控制我的webjob正在使用的连接字符串。可能还有更多的问题，但我不知道到底是什么导致了我的问题。
我有一个生产环境和一个测试部署槽。两者上都有3个网络作业在运行。所有web作业和我的网站都在其app.config中分别定义了一个连接字符串。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" />
当我进行交换时，使用的连接字符串也会被交换，我已经读到这是按设计的。现在，我希望我的测试环境始终指向我的测试数据库，所以在交换之后，我尝试在azure门户中覆盖我的连接字符串，但这没有效果。测试环境仍在使用生产数据库。
只有在我将我的本地版本（连接字符串指向TestDB）发布到staging之后，我才看到我的测试网站再次指向TestDB（为什么它没有被Azure Portal连接字符串设置覆盖？）
然而，昨晚，我做了一个交换，将我的连接字符串（在app.config和web.config中）设置为TestDB，发布到testEnvironment，还将webjobs发布到testEnvironment。他们仍然与productionDB合作。。。我登录到我的azure门户->测试部署槽。它显示没有网络作业（虽然我确信它们正在运行）。
注意：自从我使用网络作业以来，我在发布方面遇到了很多问题。因此，出版也有可能出了问题。
大量的文字，大多是试图阐述我的困惑。这可能归结为几个问题：
在什么情况下，azure门户连接字符串设置会覆盖web/app.config中的连接字符串？
为什么我的网络作业在连接字符串方面显示出不一致的行为？
我如何才能一劳永逸地摆脱这种手动网络作业发布的无稽之谈，我正在使用settings.job发布时间表网络作业的方式，这解决了我的一些问题，但不是所有问题。
下面的博客文章应该会回答您的部署槽问题。
简而言之：
- 门户连接字符串始终覆盖web应用程序或web作业web.config/app.config连接字符串
- 门户有时会显示有关网络作业的无效数据（Azure门户错误），查看这些数据的一种可靠方法是访问https://｛sitename｝.scm.azurewebsites.net/api/webjobs
- 只需确保将二进制文件部署到正确的位置（`d:\home\site\wwwroot\app_data\jobs\{job_type}\{job_name}