调试 AzureFunction 以及部署 azure 函数时缺少 ProviderName [英] Missing ProviderName when debugging AzureFunction as well as deploying azure function

查看:17
本文介绍了调试 AzureFunction 以及部署 azure 函数时缺少 ProviderName的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在获取 DbContext 以从我的 local.settings.json

I have an issue getting a DbContext to correctly pull my connection string from my local.settings.json

上下文:

  • 这是一个 Azure 函数项目
  • 主要问题代码在System.Data.Entity.Internal.AppConfig
  • 虽然我有一个 local.settings.json 文件,但这不是 dotnet 核心.这是 .net 4.6.1
  • This is an Azure function project
  • The main problem code is in System.Data.Entity.Internal.AppConfig
  • Although I have a local.settings.json file this is not dotnet core. It's .net 4.6.1

错误信息:

'应用程序配置文件中的连接字符串 'ShipBob_DevEntities' 不包含所需的 providerName 属性."'

'The connection string 'ShipBob_DevEntities' in the application's configuration file does not contain the required providerName attribute."'

Json 配置:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "AzureWebJobsDashboard": ""
},

"ConnectionStrings": {
"ShipBob_DevEntities": {
  "ConnectionString": "metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string='data source=***;initial catalog=***;persist security info=True;User Id=***;Password=***;;multipleactiveresultsets=True;application name=EntityFramework'",
  "providerName": "System.Data.EntityClient"
    }
  }
}  

测试的配置版本:

  • 将提供者名称移动到实际的 ConnectionString 令牌值中:发生相同的错误
  • ConnectionString 属性中的 provider 属性设置为 EntityClient:这没有任何作用
  • 使 ShipBob_DevEntities 成为一个字符串值 = ConnectionString 的值:这会引发新的错误,例如

  • Moving the provider name into the actual ConnectionString token value : same error ocurrs
  • Setting the provider attribute inside the ConnectionString attribute to EntityClient: this did nothing
  • Making ShipBob_DevEntities a string value = to the value of ConnectionString : this throws new errors the likes of which are

不支持关键字元数据

  • 我尝试使用 ADO 连接字符串,该字符串引发 code first 异常,当您的连接字符串在 database first 方法中不正确时,似乎会发生该异常.

  • I tried using an ADO connection string which throws a code first exception which seems to occur when your connection string is incorrect in a database first approach.

    我冒昧地使用 dotPeek 反编译了 EntityFramework.dll,并将问题追溯到 System.Data.Entity.Internal.LazyInternalConnection.TryInitializeFromAppConfig.在这个方法中,有一个对 LazyInternalConnection.FindConnectionInConfig 的调用,它会输出一个 ConnectionStringSettings 对象,该对象的 ProviderName 值设置为 null.不幸的是,我无法调试它似乎用来生成这个值的 AppConfig.cs 类,所以我被卡住了.

    I've taken the liberty to decompile EntityFramework.dll using dotPeek and have traced the problem down to System.Data.Entity.Internal.LazyInternalConnection.TryInitializeFromAppConfig. Inside this method there is a call to LazyInternalConnection.FindConnectionInConfig which spits out a ConnectionStringSettings object that has it's ProviderName value set to null. Unfortunately I am unable to debug the AppConfig.cs class which it seems to use to generate this value so I am stuck.

    到目前为止,我已经查阅了这两篇文章.其中之一规定将提供者名称作为自己的令牌;但是,这不起作用.

    So far I have consulted these two articles. One of which states to put the provider name as it's own token; however, this is not working.

    https://github.com/Azure/azure-functions-cli/问题/193
    https://github.com/Azure/azure-functions-cli/issues/46

    有谁知道在 local.settings.json 中用于实体框架连接的正确格式吗?

    Does anyone know the correct format to use in local.settings.json for an Entity Framework connection?

    推荐答案

    所以解决方案最终变得微不足道.local.settings.json 中指定的 ProviderName 属性必须是驼峰式的.

    So the solution ended up being trivial. The ProviderName attribute specified in local.settings.json MUST be camel case.

    来自原始的 git hub 讨论:
    https://github.com/Azure/azure-functions-cli/issues/46
    将提供者名称显示为 pascal 大小写

    From the original git hub discussions :
    https://github.com/Azure/azure-functions-cli/issues/46
    Shows the provider name as being pascal case

    https://github.com/Azure/azure-functions-cli/问题/193
    以伪代码显示提供者名称为驼峰式很容易错过,但您的配置部分必须完全如下

    https://github.com/Azure/azure-functions-cli/issues/193
    Shows the provider name being camel case in pseudo code It was very easy to miss but your config section must be exactly as follows

    "ConnectionStrings": {
    "ShipBob_DevEntities": {
      "ConnectionString": "metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string='data source=***;initial catalog=***;persist security info=True;User Id=***;Password=***;;multipleactiveresultsets=True;application name=EntityFramework'",
      "ProviderName":  "System.Data.EntityClient"
      }
    }  
    

    以下几点很重要:

    • 确保您的连接字符串包含元数据信息
    • 如果从 xml 配置中复制字符串,请确保对撇号进行转义
    • 确保 ProviderName 属性是 camel case
    • 确保提供程序名称为 System.Data.EntityClient

    注意,这个答案假设您正在尝试使用 DbContext 的无参数构造函数.如果您正在创建新代码,您可以轻松地关注第二个已投票的答案

    我想出了一种方法来规避提供者名称问题,同时仍然保留使用门户配置和部署槽.它涉及使用静态属性设置数据库上下文的默认连接字符串

    I figured out a way to circumvent the provider name issue while still retaining the use of the portal config and thus deployment slots. It involves setting the default connection string of db context using static properties

    private static string _connectionString = "name=ShipBob_DevEntities";
    
        static ShipBob_DevEntities()
        {
            if(!string.IsNullOrEmpty(System.Environment.GetEnvironmentVariable("AzureFunction")))
            {
                var connectionString = System.Environment.GetEnvironmentVariable("EntityFrameworkConnectionString");
    
                if (!string.IsNullOrEmpty(connectionString))
                {
                    _connectionString = connectionString;
                }
            }
        }
    
        public ShipBob_DevEntities()
            : base(_connectionString)
        {
            this.Configuration.LazyLoadingEnabled = false;
        }  
    

    这涉及到开发人员在 azure 门户中创建一个应用设置作为标志.就我而言,它是 AzureFunction.这可确保我们的代码仅在 azure 函数中运行,并且此 DbContext 的所有其他客户端,无论是 Web 应用程序、Windows 应用程序等,仍然可以继续按预期运行.这还涉及将您的连接字符串作为 AppSetting 而不是实际连接字符串添加到 azure 门户.请使用包含他们元数据信息但不包括提供者名称的完整连接字符串!

    This involves the developer to create an app setting in the azure portal as a flag. In my case it is AzureFunction. This makes sure that our code is only run in an azure function and all other clients of this DbContext, whether they be web apps, windows apps, etc, can still continue behaving as expected. This also involves adding your connection string to the azure portal as an AppSetting and not an actual connection string. Please use the full connection string including them metadata information but without the provider name!

    如果您首先使用 db,您将需要编辑自动生成的 .tt 文件 t4 模板以确保此代码不会被覆盖.

    You will need to edit your auto generated .tt file t4 template to make sure this code does not get overridden if you are using db first.

    这是 T4 语法的链接:https://docs.microsoft.com/en-us/visualstudio/modeling/writing-a-t4-text-template

    Here is a link on the T4 syntax: https://docs.microsoft.com/en-us/visualstudio/modeling/writing-a-t4-text-template

    这里是对 EF T4 模板的解释:https://msdn.microsoft.com/en-us/library/jj613116(v=vs.113).aspx#1159a805-1bcf-4700-9e99-86d182f14>

    And here is an explanation on EF T4 templates: https://msdn.microsoft.com/en-us/library/jj613116(v=vs.113).aspx#1159a805-1bcf-4700-9e99-86d182f143fe

    这篇关于调试 AzureFunction 以及部署 azure 函数时缺少 ProviderName的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

  • 查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆