我们的一位客户遇到了我们无法重现的问题。我们使用 SPFile.Properties 以编程方式将文档的属性复制到目标文件。但是，由于某种原因，文件的属性与存储文件的列表中指定的元数据不匹配。
现在，我们可能可以通过复制 SPFile.Item.Properties（尚未测试）来解决这个问题，但我只是想知道在什么情况下 SPFile.Properties 不等于 SPFile.Item.Properties。
更新：我们刚刚收到客户的更新。使用 SPFile.Item.Properties 始终返回最新信息。但是，我们仍然想了解最初的问题。
SPFile.Properties和字段之间存在细微差别，SPFile.Item第一个调用要慢得多。
您很可能已经看过 Microsoft Office 文档的“属性”窗口（这个 - http://dradisframework.org/images/tutorial/custom_document_properties.png）。这些是您访问时读取的属性SPFile.Properties。读取它们很慢，因为有一些代码基础结构可以解析二进制 DOC 文件并找到属性。（每个属性访问最多需要 30 毫秒左右）在此处查看更多信息：http: //msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
在 SharePoint 中，每个项目都是一个SPListItem，其字段值（我在这里没有故意使用“属性”一词）存储在 Sharepoint 的内容数据库中。因此，当您访问 时SPFile.Item.Properties，您实际上会查看SPListItem文件附加到的 ，并从 SharePoint 的内容数据库中查看其属性。
当您上传设置了某些“Office 属性”的文件时，幕后发生的事情是 SharePoint 将它们复制到SPListItem. （这里有一些关于它的信息：http ://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx ）
这就是为什么这些属性通常具有相同的值，但只有当 SharePoint 知道如何从您的文件中读取元数据并将其写回时才会发生这种情况。因此，如果您将.txt文件放入 SharePoint 存储中，您将不会得到任何SPFile.Properties回报。
用户将始终在文档库中看到 ListItem 属性，而不是 SPFile 属性。因此，在副本中使用 ListItem 属性是可行的方法。
我相信这个问题与 Sharepoint 属性升级/降级功能有关，该功能使文档属性能够嵌入到物理 MSOffice 文件中并随它一起传送到客户端等。但是，目前仅支持 Office 文件类型（据我所知） .
乔纳森
试图为 sharepoint 找到“官方记录”的任何内容几乎是不可撤销的。:-D。在线文档很烂，您最好使用博客条目等。
PS我在这里同意亚历克斯。尽管 SPFile 永远不会存在于没有伴随 SPListItem 的列表中，但两者之间的连接可能会损坏（即能够编辑列表项但文件不可打开）。这对我来说表明有关 2 的信息存储在内容数据库的不同位置。我以前也有过这种情况。
