АКТУАЛИЗИРАНЕ: Един анонимен плакат оставил голям коментар за вътрешните имена. Не забравяйте да го прочетете.

Когато работите със събитие приемници и други код, който адресира елементи чрез обектния модел на SharePoint списък, Аз често правят грешки, които генерира тази грешка по време на изпълнение:

Грешка при зареждане и събитие получател Conchango.xyzzyEventReceiver в xyzzy, Версия = 1.0.0.0, Култура = неутрална, PublicKeyToken = 0dc50a750396c3ac. Допълнителна информация е по-долу. : Стойността не попада в очаквания диапазон.

Мисля, че това е доста обща грешка, която потенциално е причинена много различни начини. Въпреки това, един прост обяснение е, че аз съм съотнасяне поле неправилно. Ако името на полето "Дата на падеж", Аз трябва да го позоваване като тази в събитие получател:

свойства.Елемент от списък["Дата на падеж"]

Когато грешите или да използвате грешен случая, когато се обръщате към полето, SharePoint генерира по-горе споменати runtime грешка. За пример, Това е грешно:

свойства.Елемент от списък["дата на падеж"]

</край>

Абонирайте се за моя блог.

За да заобиколите KPI проблем Аз написах за тук, Аз направих някои тестване и открих че KPI работа срещу папки с мета данни по същия начин, че те работят срещу документи или списъка елементи. Аз се оказа го чрез създаване на нов тип съдържание на базата на типа на съдържание на папка и след това се добавя няколко полета. Съм създал някои показатели и се оказа че KPI работи както се очаква. Това е добра новина. Това не е съвършен, тъй като тренировка надолу получавате от KPI срещу папки не е точно това, което искате. Това не е твърде много е недостатък в моя случай, защото 1) крайните потребители не знаят по-добре и 2) тренировка надолу отива в папка. Те щракнете върху името на папката и те са в елемента. Това е две кликвания вместо един, което не е края на света.

Това течеше добре с работата правя. Аз съм създаване на папка за всеки документ, който се качва. Това се прави чрез получател на събитие. Като резултат, Това е едно парче от тортата да се запази родителската папка мета данни в синхрон с KPI задвижване мета данни от самия тъй като водопровод е вече налице файл. Това ми позволява да имам KPI и да ги ям също 🙂

Аз modified събитие приемника да добави папката и след това тази нова папка на тип съдържание към моя потребителски тип KPI-приятелски съдържание. Този късче на код did определителен член хитрост:

 SPFolderCollection srcFolders = targetWeb.GetFolder("Документи").Подпапките;
  Папка SPFolder addedFolder = srcFolders.Add(свойства.ListItem.ID.ToString());

  SPContentTypeId kpiCT = нов SPContentTypeId("0x0120002A666CAA9176DC4AA8CBAA9DC6B4039F");
  addedFolder.Item["Идентификатор на тип съдържание"] = kpiCT;
  addedFolder.Item.Update();

За да намерите действителните ИД на тип съдържание, Достъп до този тип съдържание чрез настройки на сайта и копие/тесто то от определителен член URL както е показано:

</край>

Абонирайте се за моя блог!

Аз мразя да го призная, но аз се борят с този един цял ден. Моят събитие приемник трябва да актуализирате поле на родителската папка. Това малко показва как да го направя:

частни невалидни UpdateParentFolder(SPItemEventProperties имоти)
{

Папка SPFolder thisItemFolder = свойства.ListItem.File.ParentFolder;
thisItemFolder.Item["Състояние на одобрение за ZZ"] = "Добрата новина, всеки!";
thisItemFolder.Item.Update();


} // UpdateParentFolder

В този случай, Аз съм на работа с библиотека с документи и свойствата са идващи от ItemAdded събитие.

Номерът е, че не можете да получите папка SPFolder на артикула директно от самия елемент (т.е.. свойства.ListItem.Folder е null). Вместо това, преминете към свързания файл на елемента от списъка и да получите папка на файла.

</край>

Абонирайте се за моя блог!

Аз съм сигурен, че аз не съм първият човек, който излезе с това. Въпреки това, Аз не съм забелязал някой публикува трик като този, тъй като аз започнах да отделя специално внимание към Общността през юли. Така, Мислех, че ще го публикуваме този бърз и лесен debug съвет.

Аз съм работи по получател на събитие, което започна да генерира тази грешка в 12 кошер:

Грешка при зареждане и събитие получател Conchango.xyzzyEventReceiver в xyzzy, Версия = 1.0.0.0, Култура = неутрална, PublicKeyToken = blahbalhbalh. Допълнителна информация е по-долу. : Обект номер не настроен на една инстанция на обект.

Аз не знам къде е въведено този бъг, защото е направил твърде много неща в един от моите код/разположи/изпитвателни цикли.

Аз се опитах този разтвор да се ми pdb там с надеждата, че SharePoint 12 кошер ще покаже проследяването на стека, но няма късмет. Аз не знам дали това е възможно и ако някой прави, Моля да ме уведомите 🙂

Знам, че е възможно да Напишете вашия собствен регистър съобщения до 12 кошер. Честно казано, Исках нещо малко по-страшно и по-бързо за изпълнение.

Това ми хрумна, че мога да получа поне някои основни следа информация чрез улавяне и повторно хвърляне общи изключения като този:

  Опитайте {
    UpdateEditionDate(имоти);
  }
  улова (Изключение e)
  {
    хвърлят нов Изключение("Експедитор, UpdateEditionDate(): Изключение: [" + e.ToString() + "].");
  }

Това се появи в 12 Кошера thusly:

Грешка при зареждане и събитие получател Conchango.xyzzyEventReceiver в xyzzy, Версия = 1.0.0.0, Култура = неутрална, PublicKeyToken = blahblahblah. Допълнителна информация е по-долу. : Експедитор, UpdateEditionDate(): Изключение: [System.NullReferenceException: Обект номер не настроен на една инстанция на обект. в Conchango.xyzzyManagementEventReceiver.UpdateEditionDate(Свойства на SPItemEventProperties) в Conchango.xyzzyManagementEventReceiver.Dispatcher(Свойства на SPItemEventProperties, Низ eventDescription)].

Това ми даде всички подробности, трябва да проследим този проблем и аз очаквам да се използва много върви напред.

</край>

Абонирайте се за моя блог!