Un de nos clients a un problème que nous ne pouvons pas reproduire. Nous copions programmation des propriétés d'un document à un fichier de destination à l'aide de SPFILE.PROPERTES. Toutefois, pour une raison quelconque, les propriétés du fichier ne correspondent pas aux métadonnées spécifiées sur la liste, le fichier est stocké.
Maintenant, nous pouvons probablement résoudre ceci en copiant SPFILE.Item.properties (non testé), mais je me demande simplement dans quelles circonstances SPFILE.PROPERTES est inégale à SPFILE.Item.properties.
mise à jour: nous venons de recevoir une mise à jour de notre client. En utilisant SPFILE.Iltem.Properties renvoie toujours les informations à jour. Cependant, nous aimerions toujours comprendre la question initiale.
4 Réponses :
Essayer de trouver le "fonctionnaire documenté" de quoi que ce soit pour SharePoint est assez simple. :-RÉ. Les documents en ligne sucer, vous préférez utiliser des entrées de blog, etc.
P.s. Je suis d'accord avec Alex ici. Bien qu'un SPFILE n'existe jamais dans une liste sans Splistitem accompagnant, la connexion entre les 2 peut être corrompue (c'est-à-dire pouvoir modifier l'élément de la liste, mais le fichier n'est pas disponible). Cela signifie que cela indique que les informations sur la 2 sont stockées dans différents endroits du contenu DB. J'ai eu ce qui s'est passé auparavant.
Merci, je considère les entrées de blog "Documentation officielle". En cas de SharePoint, vous prenez vraiment ce que vous pouvez obtenir.
+1 pour la documentation officielle. : D aussi, je suis d'accord avec Colin .. Il y a quelque chose qui se passe à cause de la différence entre un SPFILE et un Splistitem.
L'utilisateur verra toujours les propriétés ListItem et non les propriétés SPFILE dans une bibliothèque de documents. Ainsi, utiliser les propriétés ListItem dans la copie est la voie à suivre.
Merci Koen, y a-t-il des preuves de ceci ou est-ce une supposition éduquée? Vous vous demandez toujours pourquoi SPFILE.PROPERTES Y a-t-il du tout et ne correspond pas toujours.
Il y a une légère différence entre Vous avez probablement vu la fenêtre "Propriétés" de Microsoft Office Document (Celui-ci - http: // dradisframework.org/images/Tutorial/custom_document_properties.png ). Ce sont les propriétés qui sont lues lorsque vous accédez au Dans SharePoint, chaque élément est un Que se passe-t-il derrière la scène, lorsque vous téléchargez un fichier de «propriétés Office Propriétés», est que SharePoint les copie aux champs de même nommés dans C'est pourquoi ces propriétés ont généralement la même valeur, mais elle ne se produit que si SharePoint sait lire des métadonnées de votre dossier et les écrire. Donc, au cas où vous mettrez un fichier spfile.properties et sphile.item les champs et le premier est beaucoup plus lent à appeler.
SPFILE.PROPERTES . Les lire sont lents car il existe une infrastructure de code qui analyse le fichier DOC binaire et trouve les propriétés. (prend jusqu'à 30 ou quelque chose de millisecondes pour chaque accès des biens) Voir plus ici: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
Splistitem et ses valeurs de champ (et je n'utilise pas le mot "Propriétés" exprès ici) sont stockés dans la base de données de contenu de SharePoint. Donc, lorsque vous accédez à SPFILE.ITEM.PROPERTES , vous consultez réellement le Splistitem auquel le fichier est joint et examine ses propriétés de la base de données de contenu de SharePoint.
Splistitem . (Quelques informations à ce sujet ici: http: //weblogs.asp. NET / BSIMSER / Archive / 2004/11/22/267846.aspx )
.txt dans votre magasin SharePoint, vous n'obtiendrez aucun SPFILE.PROPERTES Retour.
J'ai marqué celui-ci comme la réponse que c'est la meilleure description jusqu'à présent (bien que je ne l'ai pas vérifié). Pourtant, cela n'explique pas pourquoi les propriétés ne sont pas complètement synchronisées.
1. Ces propriétés ne peuvent pas être synchronisées dans le cas où le type de fichier ne l'autorise pas, car il s'agit pour les fichiers .txt, .pdf et autres fichiers non office 2. Lorsque vous ouvrez un élément de la bibliothèque de documents pour l'édition dans / Formulaires / EditForm.aspx? Id = 123 , vous modifiez les valeurs SPFILE.ITEM , pas le SPFILE.PROPERTES et ceux qui peuvent être synchronisés sont plus tard sycnchronisé par SharePoint.
Je crois que cette question est liée à la fonctionnalité de promotion de la propriété SharePoint / Demotion permettant d'intégrer les propriétés de document dans le fichier MSOffice physique et de voyager avec le client, etc. Ce n'est toutefois que pris en charge pour les types de fichiers de bureau (à Ma connaissance).
Jonathan
Correct, pas différent de ce que @naivistes étage dans l'entrée marquée comme réponse.
Essayé réflecteur? Les chemins de code ont l'air très différents, donc je ne pense pas que vous puissiez compter sur SPFILE.PROPERTES == SPFILE.Item.Properties.
Je ne l'ai pas encore essayé avec un réflecteur. J'espère trouver la différence officielle «documentée» et l'expérience des personnes avec elle plutôt que d'essayer de le déduire en inverse ingénierie des DLL. (Bien que j'ai été là ;-)