实体框架4 POCO实体在单独的组件中,动态数据网站?
基本上,我想使用动态数据网站来维护 EF4 模型中的数据,其中实体位于自己的程序集中。模型和上下文位于另一个装配体中。
我尝试了这个 实体框架 4 + 自我跟踪实体 + ASP.NET 动态数据 = 错误,
但从反射中收到“不明确匹配”错误:
System.Reflection.AmbigouslyMatchException 未由用户代码处理 消息=发现不明确的匹配。 来源=mscorlib 堆栈跟踪: 在 System.RuntimeType.GetPropertyImpl(字符串名称、BindingFlags bindingAttr、Binder 绑定器、类型 returnType、Type[] 类型、ParameterModifier[] 修饰符) 在 System.Type.GetProperty(字符串名称) 在System.Web.DynamicData.ModelProviders.EFTableProvider..ctor(EFDataModelProvider dataModel,EntitySet实体集,EntityType实体类型,类型entityClrType,类型parentEntityClrType,类型rootEntityClrType,字符串名称) 在 System.Web.DynamicData.ModelProviders.EFDataModelProvider.CreateTableProvider(EntitySet 实体集,EntityType 实体类型) 在 System.Web.DynamicData.ModelProviders.EFDataModelProvider..ctor(Object contextInstance, Func1 contextFactory) 在 System.Web.DynamicData.ModelProviders.SchemaCreator.CreateDataModel(Object contextInstance, Func
1 contextFactory) 在 System.Web.DynamicData.MetaModel.RegisterContext(Func`1 contextFactory,ContextConfiguration 配置) 在 C:\dev\Puffin\Puffin.Prototype.Web\Global.asax.cs 中的 WebApplication1.Global.RegisterRoutes(RouteCollection 路由):第 42 行 在 C:\dev\Puffin\Puffin.Prototype.Web\Global.asax.cs 中的 WebApplication1.Global.Application_Start(Object sender, EventArgs e) 处:第 78 行 内部异常:
Basically I want to use a dynamic data website to maintain data in an EF4 model where the entities are in their own assembly. Model and context are in another assembly.
I tried this Entity Framework 4 + Self-Tracking Entities + ASP.NET Dynamic Data = Error
but get an "ambiguous match" error from reflection:
System.Reflection.AmbiguousMatchException was unhandled by user code
Message=Ambiguous match found.
Source=mscorlib
StackTrace:
at System.RuntimeType.GetPropertyImpl(String name, BindingFlags bindingAttr, Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers)
at System.Type.GetProperty(String name)
at System.Web.DynamicData.ModelProviders.EFTableProvider..ctor(EFDataModelProvider dataModel, EntitySet entitySet, EntityType entityType, Type entityClrType, Type parentEntityClrType, Type rootEntityClrType, String name)
at System.Web.DynamicData.ModelProviders.EFDataModelProvider.CreateTableProvider(EntitySet entitySet, EntityType entityType)
at System.Web.DynamicData.ModelProviders.EFDataModelProvider..ctor(Object contextInstance, Func1 contextFactory)
1 contextFactory)
at System.Web.DynamicData.ModelProviders.SchemaCreator.CreateDataModel(Object contextInstance, Func
at System.Web.DynamicData.MetaModel.RegisterContext(Func`1 contextFactory, ContextConfiguration configuration)
at WebApplication1.Global.RegisterRoutes(RouteCollection routes) in C:\dev\Puffin\Puffin.Prototype.Web\Global.asax.cs:line 42
at WebApplication1.Global.Application_Start(Object sender, EventArgs e) in C:\dev\Puffin\Puffin.Prototype.Web\Global.asax.cs:line 78
InnerException:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我最近遇到了与此类似的问题。这与我的模型中的继承有关。我有一个资源实体,它派生了人员、设备等类型,并且在这些实体中我覆盖了几个属性,但错误地给了它们不同的签名。我将描述我的场景,希望它会有所帮助。
为了能够足够深入地调试框架并查看所有变量值,您必须禁用优化:
Link
我在 Global.asax 中注册上下文时看到了模糊匹配错误:
进入 RegisterContext 方法,我到达 System.Web.DynamicData.ModelProviders.EFDataModelProvider 时,有一段代码通过遍历 EFDataModelProvider 的构造函数中的继承层次结构来加载模型中的所有实体。
while (objectStack.Any()) {
EntityType 实体类型 = objectStack.Pop();
if (entityType!= null) {
// 当我们处于另一个根类型(没有基本类型的类型)时更新实体集。
if (entityType.BaseType == null) {
currentEntitySet =EntitySetLookup[实体类型];
我
在这里放置了一个断点,并且能够看到在我的 Equipment 实体(派生自 Resource)上调用 CreateTableProvider 时发生了模糊匹配。
从原始异常回顾堆栈跟踪(我应该首先完成!)我在 System.Web.DynamicData.ModelProviders.EFTableProvider.IsPublicProperty 的构造函数中放置了一个断点,并观察哪个属性/方法/无论是什么导致了不明确的匹配——对我来说,这最终是一个名为资源的导航属性(资源本身就是一个层次结构),我在设备中覆盖了它。
在设备的分部类中,我有:
但在父类资源中,资源被定义为:
当这些属性由 IsPublicProperty 中的 .GetProperty(propertyName) 加载时,它们具有相同的名称但不同的签名(因为我错误地给了它们不同的返回类型),因此不清楚应该仅根据名称加载哪个。我纠正了我的错误,并让我的 Equipment 类中的 Resources 返回一个 ICollection,然后繁荣——不再有歧义的匹配。
不确定这是否有帮助,但如果您以类似的方式逐步执行,您应该能够准确找到导致不明确匹配的原因。
I came across a similar problem to this recently. It had to do with inheritance in my model. I had a Resource entity that had derived types of Person, Equipment, etc. and in those I had overridden a couple properties, but by mistake gave them different signatures. I'll describe my scenario and hopefully it will help.
To be able to debug deep enough into the framework, and see all the variable values, you will have to disable optimizations:
Link
I was seeing the Ambiguous Match error when registering the Context in Global.asax as you were:
Stepping into the RegisterContext method, I got to System.Web.DynamicData.ModelProviders.EFDataModelProvider there is section of code that loads all the Entities in the model by traversing the inheritance hierarchy in the constuctor for EFDataModelProvider.
while (objectStack.Any()) {
EntityType entityType = objectStack.Pop();
if (entityType != null) {
// Update the entity set when we are at another root type (a type without a base type).
if (entityType.BaseType == null) {
currentEntitySet = entitySetLookup[entityType];
}
I put a breakpoint in here and was able to see that Ambiguous Match was occurring for me when calling CreateTableProvider on my Equipment entity (which was derived from Resource).
Looking back at the Stack Trace from the original exception (which I should have done in the first place!) I put a breakpoint in the constructor for System.Web.DynamicData.ModelProviders.EFTableProvider.IsPublicProperty and watched to see which property/method/whatever was causing the ambiguous match -- for me this ended up being a navigation property called Resources (Resources are themselves a hierarchy) that I had overridden in Equipment.
In the partial class for Equipment, I had:
but in the parent class, Resource, Resources was defined as:
When these Properties are being loaded by the .GetProperty(propertyName) in IsPublicProperty, they have the same name but different signatures (because I had given them different return type by mistake) so it isn't clear which shoudl be loaded based on name alone. I corrected my mistake and made Resources in my Equipment class return an ICollection, and boom -- no more ambiguous match.
Not sure if this will help or not, but if you step through in a similar way you should be able to find exactly what is causing the ambiguous match.