实体框架在本地工作，但不在天蓝色 [英] Entity framework work locally but not on azure

查看：144
本文介绍了实体框架在本地工作，但不在天蓝色的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我有一个在本地完美工作的网络项目。
但是当我在Azure上发布的网站中更改连接字符串以连接到SQL Azure上的数据库时，它将开始提供此错误。

  System.Data.Entity.Infrastructure.UnintentionalCodeFirstException：使用数据库优先和模型优化开发的T4模板生成的代码在代码优先模式下使用可能无法正常工作。要继续使用Database First或Model First，请确保在执行应用程序的配置文件中指定了Entity Framework连接字符串。要使用从数据库优先或模型优先生成的这些类，使用代码首先使用属性或DbModelBuilder API添加任何其他配置，然后删除引发此异常的代码。 C：\a\src\MyProject\Model.Context.cs中的MyClass.OnModelCreating（DbModelBuilder modelBuilder）中的
：System.Data.Entity.Internal.LazyInternalContext.CreateModelBuilder中的行25 
 （）
在System.Data.Entity.Internal.LazyInternalContext.CreateModel（LazyInternalContext internalContext）
在System.Data.Entity.Internal.RetryLazy`2.GetValue（TInput输入）
在系统.Data.Entity.Internal.LazyInternalContext.InitializeContext（）
在System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType（Type entityType）
在System.Data.Entity.Internal.Linq.InternalSet`1 .Initialize（）
在System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext（）
在System.Data.Entity.Infrastructure.DbQuery`1.System.Linq.IQueryable.get_Provider （）
在System.Linq.Queryable.Select [TSource，TResult]（IQueryable`1 source，Expression`1 selector）

我的配置有：

 的ConnectionStrings> 
< add name =MyDBEntitiesconnectionString =metadata = res：//*/MyModel.csdl | res：//*/MyModel.ssdl | res：//*/MyModel.msl; provider = System .Data.SqlClient; provider connection string =& quot; Server = tcp：[Removed] .database.windows.net，1433; Database = MyDB; User ID = [Removed]; Password = [Removed]; Trusted_Connection = False; Encrypt = True; Connection Timeout = 30;& quot; providerName =System.Data.EntityClient/> 
< add name =MyDBconnectionString =metadata = res：//*/Model.csdl | res：//*/Model.ssdl | res：//*/Model.msl; provider = System .Data.SqlClient; provider connection string =& quot; Server = tcp：[Removed] .database.windows.net，1433; Database = MyDB; User ID = [Removed]; Password = [Removed]; Trusted_Connection = False; Encrypt = True; Connection Timeout = 30;& quot; providerName =System.Data.EntityClient/> 
< / connectionStrings>

我在本地使用我的单元测试与该连接字符串进行测试，它可以从本地连接到SQL的本地机器Azure数据库。
任何帮助赞赏。

解决方案

我今天遇到了这个确切的问题;这是我第一次部署到Azure。我一直在拉我的头发，除了我没有任何留下。



就像原始的海报一样，我在这些测试中配置：




  • 从Visual Studio运行WCF Web应用程序与本地DB - 成功

  • 部署WCF从Visual Studio到本地IIS的Web应用程序，针对本地DB运行 - 成功

  • 从Visual Studio向Azure SQL DB运行WCF Web App - 成功

  • 通过Visual Studio将WCF应用程序部署到Azure上，运行于Azure SQL DB - FAILURE !!



在阅读了另一篇文章（代码优先与数据库优先）后，我得到一个提示。那个帖子说，如果连接字符串有元数据，EF认为它是Model First或Database First，但如果它是一个简单的连接字符串，EF认为它是Code First。我浏览了部署的Azure网站的web.config，并确认连接字符串对Model-First元数据的正确引用。那么是什么问题？



我认为，这个Azure网站也许没有阅读web.config的连接字符串。回想起我如何创建Azure网站，我记得我已经给了Azure SQL DB一个别名，其名称与我的连接字符串'label'在web.config中一样。强调>要澄清：在Azure管理控制台中




  • 我去了网站设置，并检查了连接字符串设置烘焙对我的Azure网站作为创建网站与DB的连接字符串'handle'的副作用是SsnCustInfoModelContainer - 我错误地给了连接相同的'handle'/'别名'作为我的web.config'handle'的连接字符串，认为这将有所帮助。相反，当EF查找连接字符串时，它发现这个别名句柄，这是一个不含元数据的简单SQL连接字符串。这个'别名'掩盖了web.config中指定的真正的连接字符串。



所以我销毁了我的Azure SQL DB和我的Azure网站。然后我重新创建了Azure网站，但是这次我要求连接到相关联的Azure SQL Server的SsnCustInfoModelContainer_Proto的连接字符串别名。从本地SQL Server Management Studio初始化Azure SQL DB后，我再次将WCF Web应用程序部署到Azure网站（当然，我不得不下载新的部署配置文件），我再次尝试了该应用程序。这一次它的工作 - '别名'SsnCustInfoModelContainer_Proto没有与EF冲突，没有被EF找到。 EF代替继续在web.config中找到所有正确的元数据的真正的连接字符串。解决问题。


I have a web project which works perfectly locally. But when I change the connection string in my published web site on Azure to connect to my database on SQL Azure it will start giving this error.

System.Data.Entity.Infrastructure.UnintentionalCodeFirstException: Code generated using the T4 templates for Database First and Model First development may not work correctly if used in Code First mode. To continue using Database First or Model First ensure that the Entity Framework connection string is specified in the config file of executing application. To use these classes, that were generated from Database First or Model First, with Code First add any additional configuration using attributes or the DbModelBuilder API and then remove the code that throws this exception.
   at MyClass.OnModelCreating(DbModelBuilder modelBuilder) in c:\a\src\MyProject\Model.Context.cs:line 25
   at System.Data.Entity.Internal.LazyInternalContext.CreateModelBuilder()
   at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext)
   at System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input)
   at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()
   at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
   at System.Data.Entity.Internal.Linq.InternalSet`1.Initialize()
   at System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext()
   at System.Data.Entity.Infrastructure.DbQuery`1.System.Linq.IQueryable.get_Provider()
   at System.Linq.Queryable.Select[TSource,TResult](IQueryable`1 source, Expression`1 selector)

My Config has:

<connectionStrings>
    <add name="MyDBEntities" connectionString="metadata=res://*/MyModel.csdl|res://*/MyModel.ssdl|res://*/MyModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;Server=tcp:[Removed].database.windows.net,1433;Database=MyDB;User ID=[Removed];Password=[Removed];Trusted_Connection=False;Encrypt=True;Connection Timeout=30;&quot;" providerName="System.Data.EntityClient" /> 
    <add name="MyDB" connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provider=System.Data.SqlClient;provider connection string=&quot;Server=tcp:[Removed].database.windows.net,1433;Database=MyDB;User ID=[Removed];Password=[Removed];Trusted_Connection=False;Encrypt=True;Connection Timeout=30;&quot;" providerName="System.Data.EntityClient" />
</connectionStrings>

I tested using my unit test locally with that connection string and it works from my local machine connecting to SQL Azure database. Any help appreciated.

解决方案

I was having this exact problem today; it's my first time deploying to Azure. I've been pulling my hair out, except I don't have any left. I finally figured it out, and it's probably the same issue original poster here is having.

Just like the original poster, I tested in these configurations:

  • ran WCF Web App from Visual Studio against local DB -- success
  • deployed WCF Web App from Visual Studio to local IIS, ran against local DB -- success
  • ran WCF Web App from Visual Studio against Azure SQL DB -- success
  • deployed WCF App to Azure via Visual Studio, running against Azure SQL DB -- FAILURE!!

After reading another post (Code First vs. Database First) I got a hint. That post says that if "connection string has the metadata, EF thinks it is Model First or Database First" but if it's a "plain connection string, EF thinks it is Code First." I browsed the deployed Azure Web Site's web.config and confirmed that the connection string had the proper references to the Model-First metadata. So what was the problem???

I figured that perhaps the Azure Website wasn't reading the web.config's connection string. Thinking back to how I'd created the Azure Web Site, I remembered that I'd given the Azure SQL DB an alias with the exact same name as my connection string's 'label' in the web.config!! To clarify:

  • in the Azure admin console I went to the Website settings and reviewed the "connection string" settings "baked in" to my Azure web site as a side-effect of creating-website-with-DB -- connection string 'handle' was "SsnCustInfoModelContainer" -- I'd mistakenly given the connection the same 'handle'/'alias' as my web.config 'handle' for the connection string, thinking this would help. Instead, when EF looks for the connection string, it was finding this 'aliased' handle, which was a "plain" SQL connection string containing no metadata. This 'alias' masked the real connection string specified in the web.config.

So I destroyed my Azure SQL DB and my Azure Web Site. Then I recreated the Azure Web Site, but this time I asked for the connection string 'alias' of "SsnCustInfoModelContainer_Proto" for the connection to the associated Azure SQL Server. After initializing the Azure SQL DB from my local SQL Server Management Studio, I deployed the WCF web app again to the Azure Web Site (I had to download a new deployment profile, of course, to do this), I tried the app again. This time it worked -- the 'alias' "SsnCustInfoModelContainer_Proto" did not conflict with and was not found by EF. EF instead went on to find the true connection string, with all the proper metadata, in the web.config. Problem solved.

这篇关于实体框架在本地工作，但不在天蓝色的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
.NET组件控件最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆