Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Sharepoint: AddFieldAsXml Bug oder internalName != displayName

Beim pro­gram­ma­ti­schen Erstellen von benut­zer­de­fi­nier­ten Spalten (SPField) in Sharepoint sind einige Dinge zu beach­ten und erwar­ten auch beach­tet zu wer­den. Hält man sich jedoch an die Spielregeln (API Dokumentation) und erzielt trotz­dem nicht das gewünschte Ergebniss, ist wahr­schein­lich wie­der ein Sharepoint Bug gefun­den wor­den. Dies musste ich heute wie­der mal schmerz­haft fest­stel­len.

Sharepoint ver­wen­det zwei Namen um Felder zu kenn­zeich­nen. Den internalName sowie den displayName (bzw. Title). Der internalName wird von Sharepoint selbst sowie von dem Sharepoint Objekt Modell ver­wen­det um Spalten(SPField) und Objekte wie­der zu erken­nen und anzu­spre­chen. Der displayName und die Title – Eigenschaft wer­den ver­wen­det um die Darstellung der Spalten zu steue­ren. So kön­nen ein­deu­tige Namen Verwendung fin­den um Objekte ein­deu­tig anzu­spre­chen. Gleichzeitig kann der Anzeigename varia­bel gestal­tet wer­den.

So hatte ich ver­sucht eine Sharepoint Spalte über die API zu erstel­len und anschlie­ßend zur SPFieldCollection einer Liste  hin­zu­zu­fü­gen.
Dies funk­tio­nierte mit den fol­gen­den Codeschnipseln auch sehr gut.

SPField currField = colFields.CreateNewField(SPFieldTypeString, displayName);
currField.staticName = internalName;
colFields.AddFieldAsXml(currField.SchemaXml, true, SPAddFieldOptions.AddToAllContentTypes);

Anschließend beim Beschreiben der Spalte gin­gen jedoch die Probleme los.

SPField newField = newItem.Fields.GetFieldByInternalName(internalFieldName);

Laut  API Dokumentation und MSDN wel­che besagt, dass der staticName dazu dient, um den internalName zu set­zen, wäre der obige Programm – Code rich­tig. ("Gets or sets the inter­nal name of the field.")

Das Ausführen der Methode ver­ur­sachte eine ArgumentException mit der Meldung: Value does not fall wit­hin the expec­ted range.

Darfaufhin begann ich ein wenig wei­ter zu for­schen (Danke an Sharepoint Manager) und fand her­raus, dass die AddFieldAsXml Methode in Verbindung mit einem SPField wel­ches mit CreateNewField erzeugt wurde einen Bug von Sharepoint her­vor­ruft. AddFieldAsXml setzt den displayName wie ange­ge­ben, aber lei­der auch den internalName mit dem Wert des dis­play Namens. Das hat zur Folge, dass die Spalten nicht mehr über den interalName ansprech­bar sind.

Wer jetzt also vor genau die­sem Problem ste­hen sollte, hat zwei schnelle Möglichkeiten.

  1. Die Guid des Feldes spei­chern und ver­wen­den sofern der Zugriff auf diese besteht.
    Mit Hilfe die­ser kann eine Sharepoint Spalte sicher bestimmt wer­den.
  2. Folgenden Workaround ver­wen­den.

Workaround:

Die Lösung des Problems ist regel­recht sim­pel. Es wird der glei­che obige Code ver­wen­det um das SPField zu erstel­len, jedoch als displayName der internalName gesetzt. Dadurch legt Sharepoint die Spalte mit dem rich­ti­gen internalName an. Sobald die Spalte ange­legt wurde, muss nur noch der displayName geän­dert wer­den.

string internalName = "internerName";
string displayName = "displayName";
SPField currField = colFields.CreateNewField(SPFieldTypeString, internalName);
colFields.AddFieldAsXml(currField.SchemaXml, true, SPAddFieldOptions.AddToAllContentTypes);
SPField rewriteField = colFields[internalName];
rewriteField.Title = displayName;
rewriteField.Update();

Wird die GetField- oder GetFieldByInternalName –  Methode jetzt mit dem internalName auf­ge­ru­fen lie­fert sie die gewünschte Spalte.

Related Posts

Neuer Blogpost zu #Sharepoint #Bug bei AddFieldAsXml (internalName und displayName) im #Communardo #Techblog: http://tinyurl.com/lvl6tf
This com­ment was ori­gi­nally pos­ted on Twitter

Sharepoint: internalName != displayName at #Communardo #Techblog #Sharepoint #Bug http://bit.ly/EhFiZ
This com­ment was ori­gi­nally pos­ted on Twitter

Comments are closed.

Pin It on Pinterest