2016-04-26 8 views
0

Ich versuche, eine Kalenderliste in SharePoint 2010 programmgesteuert zu erstellen, wenn eine bestimmte Liste mit einer Sandbox-Lösung erstellt wird. Ich habe einen ListAdded ListEventReceiver implementiert, um den Code zum Generieren des Kalenders auszuführen.Erstellen einer Liste in ListAdded List Ereignisempfänger

public class GenerateCalendar : SPListEventReceiver 
{ 
    public override void ListAdded(SPListEventProperties properties) 
    { 
     base.ListAdded(properties); 

     // Exit out if this is not a MyList type 
     if(!IsMyList(properties)) 
     return; 

     string calendarTitle = properties.List.Title + " Calendar"; 

     SPWeb spWeb = properties.Web; 
     SPListTemplateType type = new SPListTemplateType(); 
     type = SPListTemplateType.Events; 

     // Execution breaks here: 
     Guid listGuid = spWeb.Lists.Add(calendarTitle, "Associated Calendar", type); 
     SPList newList = spWeb.Lists[listGuid]; 
     newList.OnQuickLaunch = properties.List.OnQuickLaunch; 
     newList.Update(); 
    } 
} 

Als ich spWeb.Lists.Add nennen (...), erhalte ich eine SPException (Die Sandbox-Code-Ausführung angefordert wurde abgelehnt, weil der Sandkasten-Code Host-Dienst zu sehr damit beschäftigt war die Anfrage zu bearbeiten.)

Von der MSDN-Dokumentation kann ich sehen, dass die SPListCollection.Add-Methode ist in Sandboxed Solutions (https://msdn.microsoft.com/en-us/library/office/ms413986(v=office.14).aspx) verfügbar. Gibt es eine Einschränkung gegen das Erstellen einer Liste in diesem Ereignisempfänger? Weiß jemand, warum das nicht funktioniert?

Edited die generierten Feature.xml und Elements.xml Dateien hinzufügen

Feature.xml:

<?xml version="1.0" encoding="utf-8"?> 
<Feature xmlns="http://schemas.microsoft.com/sharepoint/" 
    Title="Calendar Generator" 
    Description="Generates a calendar" 
    Id="dfe3388c-c063-4873-a41b-5c066907c510" 
    Scope="Web"> 
    <ElementManifests> 
     <ElementManifest Location="GenerateCalendar\Elements.xml" /> 
    </ElementManifests> 
</Feature> 

Elements.xml

<?xml version="1.0" encoding="utf-8"?> 
<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> 
    <Receivers > 
     <Receiver> 
     <Name>GenerateCalendarListAdding</Name> 
     <Type>ListAdding</Type> 
     <Assembly>MyListGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5cff2198a602ec41</Assembly> 
     <Class>MyListGenerator.Event_Receivers.GenerateCalendar.GenerateCalendar</Class> 
     <SequenceNumber>10000</SequenceNumber> 
     </Receiver> 
     <Receiver> 
     <Name>GenerateCalendarListDeleting</Name> 
     <Assembly>MyListGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5cff2198a602ec41</Assembly> 
     <Class>MyListGenerator.Event_Receivers.GenerateCalendar.GenerateCalendar</Class> 
     <SequenceNumber>10000</SequenceNumber> 
     </Receiver> 
     <Receiver> 
     <Name>GenerateCalendarListAdded</Name> 
     <Type>ListAdded</Type> 
     <Assembly>MyListGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5cff2198a602ec41</Assembly> 
     <Class>MyListGenerator.Event_Receivers.GenerateCalendar.GenerateCalendar</Class> 
     <SequenceNumber>10000</SequenceNumber> 
     </Receiver> 
    </Receivers> 
</Elements> 

Antwort

1

Ich fand die Antwort. Scheinbar verursachte das Erstellen einer Liste innerhalb dieses Ereignisempfängers einen rekursiven Aufruf an den Ereignisempfänger, obwohl ich eine Überprüfung hatte, um auf nicht vorlagenbasierten Listen zu verzichten. Die Lösung bestand darin, einfach EventFiringEnabled = false hinzuzufügen.

... 
SPWeb spWeb = properties.Web; 
SPListTemplateType type = new SPListTemplateType(); 
type = SPListTemplateType.Events; 

EventFiringEnabled = false; // Disable event firing and create the list 
Guid listGuid = spWeb.Lists.Add(calendarTitle, "Associated Calendar", type); 
SPList newList = spWeb.Lists[listGuid]; 
newList.OnQuickLaunch = properties.List.OnQuickLaunch; 
newList.Update(); 
EventFiringEnabled = true; // Re-enable event firing 
... 
0

Sie Ereignisempfänger erstellen können, die aus ableiten SPListEventReceiver in einer Sandbox-Lösung. Der Ereignisempfänger muss jedoch in Ihrer Feature-Element-Datei declaratively registriert sein. Es kann nicht über das Objektmodell registriert werden (z. B. über einen Feature-Empfänger).

Höchstwahrscheinlich stoßen Sie auf eine Beschränkung der Ressourcenpunkte Ihre Sandbox-Lösung darf konsumieren, obwohl Sie möglicherweise auch in die absolute Grenze der Ressourcen, die pro Anforderung verbraucht werden können.

Wenn Ihre Umgebung besonders langsam ausgeführt wird, wird der Benutzercode-Dienst außerdem wiederverwendet, wenn das Zeitlimit (standardmäßig 30 Sekunden) während einer einzelnen Anforderung überschritten wird.

Weitere Informationen finden Sie in der „Legendes Solution Monitoring“ dieses Sandkastenlösungen Dokumentation von Microsoft: https://msdn.microsoft.com/en-us/library/ff798382.aspx

Relevante Auszüge folgen.

Ressourcen Punkte:

Wenn die Lösungen in einer Websitesammlung die tägliche Ressource Punkteverteilung für die Websitesammlung überschreiten, nehmen Sharepoint jede Sandbox-Lösung in der Offline-Websitesammlung für den Rest des Tages .

Ressourcenpunkte werden anhand von 14 verschiedenen Messungen berechnet, die als Ressourcenmesswerte bezeichnet werden, einschließlich CPU-Ausführungszeit, Speicherverbrauch und nicht behandelte Ausnahmen.

...

Sharepoint zählt die teuerste Ressource Maßnahme zur Summe für die Lösung, statt die Summe aller Maßnahmen.

absolute Grenzen:

Um zu verhindern, Rogue-Sandbox-Lösungen von Instabilität verursacht Sharepoint auch einzelne Sandkastenlösungen pro Anfrage überwacht. Jede der 14 Ressourcenkennzahlen enthält eine AbsoluteLimit -Eigenschaft, die eine feste Begrenzung der Ressourcen definiert, die eine Sandkastenlösung in einer einzelnen Anforderung verarbeiten kann. Wenn ein absolutes Limit überschritten wird, beendet SharePoint die Anforderung, indem der Sandbox Worker-Prozess beendet und neu gestartet wird. Zum Beispiel hat das CPU-Ausführungszeitressourcen-Measure eine absolute Standardgrenze von 60 Sekunden. Wenn eine einzelne Anforderung länger als 60 Sekunden dauert, wird der Benutzercodedienst angehalten und der Sandbox Worker-Prozess, der die Anforderung ausführt, erneut gestartet.

WorkerProcessExecutionTimeout:

Darüber hinaus enthält der Benutzercode Dienst eine Eigenschaft WorkerProcessExecutionTimeout mit einem Standardwert von 30 Sekunden genannt. Wenn dieses Zeitlimit während einer einzelnen Anforderung überschritten wird, führt der Benutzercodedienst die betreffende Anwendungsdomäne erneut aus, und die Anforderung gibt einen Fehler zurück.

+0

Es scheint keines dieser Dinge zu sein. Der Ereignisempfänger ist deklarativ registriert. Ich habe Visual Studio damit umgehen lassen, aber ich habe die Feature.xml und Elements.xml, die gegen das Beispiel in der Dokumentation generiert wurden, verifiziert und es stimmt ziemlich gut überein (mit Ausnahme des Fehlens eines ListTemplateId-Attributs im Empfänger-Tag der Elemente .xml). Ich habe meine Frage bearbeitet und die Ausgabe der Dateien bis zum Ende hinzugefügt. –

+0

Soweit das ** WorkerProcessExecutionTimeout **, ich habe es mehrmals getestet, um zu sehen, wie lange es dauert, bevor ich die Ausnahme erhalte und es war konsequent etwa 10 Sekunden. Ich habe den Wert von ** WorkerProcessExecutionTimeout ** (auf 30 gesetzt) ​​über PowerShell verifiziert und sogar versucht, ihn auf 60 zu ändern, aber es hat keinen Unterschied gemacht. Die Ausnahme tritt nach nur 10 Sekunden auf. Die Ressourcennutzung beträgt ungefähr 0,07 (obwohl diese Zahl von 0 auf 0,15 zu schwanken scheint). Irgendwelche anderen Ideen, was das verursachen könnte? –

Verwandte Themen