LinqToSharepoint 插入到具有多种内容类型的列表答案

【问题标题】：LinqToSharepoint insert to list with multiple content typesLinqToSharepoint 插入到具有多种内容类型的列表
【发布时间】：2011-12-09 09:45:44
【问题描述】：

在使用 Linq2SharePoint 时，我在将新记录插入 SharePoint 列表时遇到问题，该列表可以包含多个内容类型的项目。

我的列表及其内容类型由功能创建，并且在事件接收器内容类型绑定中为许多内容类型创建。这些实际上是一棵相互继承的类型树，它们都派生自一个自定义内容类型，而该自定义内容类型本身又派生自内置的 Item 内容类型。

我的数据上下文由 SPMetal 生成，然后使用自定义 T4 模板创建存储库层。我没有使用 Linq2SharePoint 来访问命名列表，而是为内容类型创建存储库。事实上，可以通过激活在编译时不存在的功能在任何 SPWeb 中创建有问题的列表，因此对于数据上下文是未知的。

在 MSDN 上解释说，要处理多个内容类型的列表，SPMetal 会生成数据上下文以使用最近的基本内容类型来处理这种性质的列表。请参阅此处的“为内容类型生成实体”部分http://msdn.microsoft.com/en-us/library/ff798478.aspx

基于此，我使用基本内容类型访问列表。例如假设以下内容类型层次结构：

Item
  Foo : Item
    BlueFoo : Foo
    RedFoo : Foo
      BrightRedFoo : RedFoo
      DarkRedFoo : RedFoo
    GreenFoo : Foo

然后我的列表可以包含任何 XXXFoo 内容类型的项目，并且要访问它，数据上下文使用 EntityList<Foo>。

这非常适合从列表中读取项目，尽管它们都是 Foo 类型而不是它们的派生类型（尽管这不是真正的问题，因为使用一些复杂的方法涉及对 Item 的 ICustomMapping 扩展来访问生成的隐藏内容类型字段如果需要，存储库层可以访问底层 SPListItem 并向下转换为派生类型）。

当我尝试将项目写入列表时出现问题。首先，我尝试为此目的创建一个特定的 EntityList，例如EntityList<RedFoo> 但这导致了异常。因此，我也将 Foo 类型添加到 Lists 内容类型中，并尝试使用 EntityList<Foo> 添加项目，但这会导致相同的异常。

两种情况下的异常相同，错误消息是“与映射关联的列已被删除/重命名”。对此的 Google 搜索仅找到遇到此消息的一个快乐的人 (omourad.blogspot.com/2010/06/columns-associated-with-mappings-have.html)，但他的问题是错误地命名了他的列表。这不是我的问题。

在 WWW 上搜索了几个小时后，我发现关于具有多种内容类型的 SPLists 的讨论很少，而且几乎与 Linq 和这个问题无关。 CodePlex http://sporm.codeplex.com/ 上有这个，但它有 0 次下载，并且自 2009 年以来一直很安静......

我尝试直接从数据上下文访问，而不是使用存储库层来确保问题不在我的代码中。我已经从激活了该功能的网络重新生成了数据上下文，因此我可以确定它没有不同步。

我错过了什么吗？这是通过我以某种方式错过的累积更新修复的吗？当然，我不是唯一一个尝试这样做的人吗？当您遇到问题并且您可以找到的唯一在线参考是 StackOverflow 风滚草问题时，我几乎感到孤独。一定有人能阻止这本身就是一个风滚草问题吗？

【问题讨论】：

嗨，Rob，您能介绍一下您是如何解决 Foo 问题的吗？我对您应该如何在 L2SP 中对此建模感到困惑，而且您似乎“使用一些诡计”解决了它。就您的类型问题而言，我已经成功地将子类型添加到基本类型列表中。尝试时会抛出什么异常？
这是我发布的一个问题的链接stackoverflow.com/questions/9386437/…
嗨杰森。我发布了使用 ICustomMapping 的解释和代码示例，以提供必要的“jiggery”，以便能够在您的其他问题上从 L2SP 基础实体解析派生类型。希望能帮助到你。关于我通过 L2SP 插入的问题，我并没有解决这些问题，而是很高兴当我们对 ContentTypes 进行一些更改时它们似乎消失了。经过大量挖掘，2010 年 Inherits 属性的实现肯定有一点不一致，尽管完全排除我自己的无能贡献是不公平的；）

标签： .net linq sharepoint

【解决方案1】：

[在此处插入风滚草的图形]

我对这个问题没有明确的答案，因为看起来这不是一个真正的问题，或者至少我的表现只是一个症状。或者我只是没有明确的答案，因为在 SharePoint 世界中没有明确的答案，在无法解释或证明理由的情况下说“不要做 X”或“你必须做 Y”似乎完全可以接受它。本着这种精神，我会说以下不恰当且不受支持的概括：

不要在 ContentTypes 上使用“继承”或“覆盖”属性。

听起来不错。文档看起来不错。该功能对于摆脱令人讨厌的“标题”字段之类的事情来说非常棒，但实际上它们似乎不起作用。我不知道为什么，我猜 SharePoint 团队也没有，因为他们能给我的最好的就是“发生错误”。请再试一次'或类似的。我所知道的是，如果没有这两个属性，它们赋予一切的非常理想的效果会更好。

【讨论】：