Webpart verwendet nur manchmal die Website-Vorlage, um eine neue Website zu erzeugen

Tom Scheuermann Als Antwort am 18 Okt. 2013 08:24

Evtl. fehlt einfach nur ein aktiviertes Feature ?

Nimm mal die GUID aus der Meldung "List Feature {GUID] nicht vorhanden" und vergleiche es mal mit dem Ergebnis des PS Befehls'

Get-SPFeature (muss am Server ausgeführt werden)

Auf welches Feature bezieht sich die Meldung ?

Peter Oswald Als Antwort am 18 Okt. 2013 08:37

das ist genau das Kuriosum, denn wenn ich Get-SPFeature laufen lasse, wird nichts gefunden!

Andi Fandrich Als Antwort am 18 Okt. 2013 08:42

Wenn man eine Website als Vorlage speichert, werden die Komponenten dieser Website (Inhaltstypen, Listen usw.) in Features gepackt und diese dann in der WSP-Datei abgelegt. Irgendwo in diesem Bereich muß es hier ein Problem geben. Wenn Ihr eine neue Vorlage erzeugt, solltet ihr der einen neuen Namen geben, sonst kommt sie sich mit der alten in die Quere.

Peter Oswald Als Antwort am 18 Okt. 2013 11:47

Nun, ich hätte jetzt eigentlich erwartet, dass wenn ich eine Listenvorlage in den Lösungen deaktiviere und lösche(!), dass dann auch alle übrigen Referenzen gelöscht sind, denn was macht es für einen Sinn, eine Referenz auf ein Feature zu behalten, wenn es die initiierende Komponente gar nicht mehr gibt?

Das mit dem neuen Namen ist hier leider so nicht möglich, denn wie gesagt: das entwickelte Webpart greift nur mit dem TemplateName auf die Vorlage zu. Ändert man den Namen, nur weil sich die Vorlage ändert, müsste man auch jedes Mal den Code anfassen.

Andi Fandrich Als Antwort am 18 Okt. 2013 12:16

[quote user="Peter Oswald"]Nun, ich hätte jetzt eigentlich erwartet, dass wenn ich eine Listenvorlage in den Lösungen deaktiviere und lösche[/quote]

Bei Listenvorlagen ist das auch kein Problem. Bei eigenen Websitevorlagen aber schon. Wenn Du eine Websitevorlage deaktivierst, dann werden in den daraus erzeugten Websites z.B. die Inhaltstypen entfernt (nur vom Web, nicht von den Listen). Und das ist nur ein Beispiel, es gibt noch mehr Probleme. Im Grunde ist das dasselbe, wie wenn man einfach eine eigene Solution aus der Farm entfernt. Man kann dann auch nicht erwarten, daß alles was über die Solution bereitgestellt wurde problemlos weiter funktioniert.

[quote user="Peter Oswald"]Ändert man den Namen, nur weil sich die Vorlage ändert, müsste man auch jedes Mal den Code anfassen[/quote]

Dann muß eben das Webpart flexibler werden. Man kann z.B. den Namen einstellbar machen.

Peter Oswald Als Antwort am 21 Okt. 2013 11:48

Das mit dem einstellbar ist eine gute Idee. Nun dachte ich, um das umzusetzen, würde mir

• SPSite.GetCustomWebTemplates(LCID)

die Liste der benutzerdefinierten Website-Vorlagen liefern. Eigenartigerweise kommt da nix zurück, obwohl es ja meine im Lösungskatalog gibt. Lasse ich mir mit

• site.RootWeb.GetAvailableWebTemplates(LCID)

alle Vorlagen liefern, steht meine Vorlage mit drin, und zwar mit der Eigenschaft isCustomTemplate = false.

Aber müsste eine selbst hochgeladene Lösung in den Lösungskatalog nicht automatisch das Kennzeichen isCustomTemplate erhalten?

Peter Oswald Als Antwort am 22 Okt. 2013 10:07

weiß das niemand?

Andi Fandrich Als Antwort am 22 Okt. 2013 10:25

Offenbar nicht. Ich würde mich aber auch nicht weiter drum scheren, ob das jetzt true oder false ist. Hauptsache es funktioniert.

Peter Oswald Als Antwort am 22 Okt. 2013 10:30

[quote user="Andi Fandrich"] Hauptsache es funktioniert[/quote]

lol, ja eben halt nicht so wie ich es bräuchte:

• Gib mir alle Custom Templates ohne die Standard Templates

möchte ich umsetzen.

Andi Fandrich Als Antwort am 22 Okt. 2013 11:41

Naja, der Standard ist ja bekannt und läßt sich einzeln ausfiltern. Manchmal helfen einfach nur solch schlimme Workarounds :-(

Peter Oswald Als Antwort am 22 Okt. 2013 14:50

ok, jetzt habe ich mal geworkarounded und die Website-Templates werden nun aufgelistet. Und schon laufe ich in das nächste Problem:

• ich habe jetzt die alten Custom Templates alle deaktiviert und gelöscht und ein neues Template erstellt und aktiviert

Wenn ich mein Webpart neu lade, zeigt das mir prompt die alten Templates an!?

Habe ich da jetzt noch ein Caching-Problem? Selbst wenn die alten Templates aus dem Websitesammlung-Papierkorb lösche, zeigt das Webpart die noch an...!?

Andi Fandrich Als Antwort am 22 Okt. 2013 15:05

Ich weiß nicht, wie Du die Vorlagen ermittelst, aber SPWeb.GetAvailableWebTemplates() sollte die nicht mehr liefern.

[quote user="Peter Oswald"]ich habe jetzt die alten Custom Templates alle deaktiviert und gelöscht[/quote]

Das solltest Du in einer produktiven Umgebung später niemals tun. Du machst damit die aus den Vorlagen erstellten Websites kaputt.

Peter Oswald Als Antwort am 22 Okt. 2013 15:15

die aus den alten Vorlagen erstellten Websites gibt es nicht mehr. Selbst wenn, welche Auswirkung auf das Lesen des Website-Katalogs sollte das haben? Wenn ich GetAvailableWebTemplates() aufrufe, erwarte ich jetzt unabhängig davon die aktuelle Liste der Vorlagen. Aber im Moment sieht es ja so aus, als könnte das Webpart nur die Templates sehen zum Zeitpunkt des Einspielens des Webparts.

Andi Fandrich Als Antwort am 22 Okt. 2013 15:22

[quote user="Peter Oswald"]die aus den alten Vorlagen erstellten Websites gibt es nicht mehr[/quote]

Das sollte nur eine freundliche Warnung sein das nicht auf einem Produktivsystem zu machen :-)

[quote user="Peter Oswald"]Selbst wenn, welche Auswirkung auf das Lesen des Website-Katalogs sollte das haben?[/quote]

Auf den katalog hat das natürlich keinerlei Auswirkungen.

[quote user="Peter Oswald"]Aber im Moment sieht es ja so aus, als könnte das Webpart nur die Templates sehen zum Zeitpunkt des Einspielens des Webparts[/quote]

Das kann ich nicht glauben. Du holst die verfügbaren Vorlagen ja per Code und der Code wird zu einem bestimmten Zeitpunkt ausgeführt. Mit dem Zeitpunkt des Erstellens des Webparts hat das nichts zu tun.

Peter Oswald Als Antwort am 22 Okt. 2013 15:34

ja, dachte ich auch nicht zu glauben, aber es gibt Sätze wie

"In some instances, the specified custom site definition is not found because the custom site definition is not yet in the cache...."

auf http://msdn.microsoft.com/en-us/library/sharepoint/ms466366.aspx 

Andi Fandrich Als Antwort am 22 Okt. 2013 15:42

Das in dem Link Beschrieben gilt zwar nicht explizit für Vorlagen, die durch "Als Vorlage speichern" entstanden sind (die werden völlig anders abgelegt), aber möglich ist natürlich alles...

Peter Oswald Als Antwort am 23 Okt. 2013 08:38

Interessanterweise ist dieser "Cache" jetzt über Nacht wohl aktualisiert worden, denn heute morgen werden auch die neuen Vorlagen aufgelistet, ohne dass ich programmatisch etwas verändert hätte. Kurioserweise meckert das System aber bei Auswahl einer neuen Vorlage, dass keine Rechte vorhanden wären. Die Lösung neu einspielen scheint auch reinigende Auswirkung auf alles zu haben, denn danach funkt alles...!?

Andi Fandrich Als Antwort am 23 Okt. 2013 09:04

Sowohl das "über Nacht warten" als auch ein Neueinspielen der Lösung haben denselben Effekt, nämlich daß der Application Pool recycled und dadurch der Cache geleert wird. Steht auch in dem von Dir geposteten Link...

Peter Oswald Als Antwort am 23 Okt. 2013 09:18

hm, das mit dem über Nacht hätte ich jetzt so nicht herausgelesen, aber wenn du s sagst, wird s wohl so sein :-) Bisher bin ich noch über kein Caching dieser Art gestolpert. Eine Kleinigkeit, die nicht groß an die Wand gepinnt ist, aber in diesem Fall bei mir für viel Erstaunen gesorgt hat.

Andi Fandrich Als Antwort am 23 Okt. 2013 09:57

[quote user="Peter Oswald"]das mit dem über Nacht hätte ich jetzt so nicht herausgelesen[/quote]

Das ist die Standardeinstellung. Kannst Du im IIS Manager beim Application Pool nachschauen.

Peter Oswald Als Antwort am 25 Okt. 2013 08:54

leider muss ich nochmal daherkommen und eine Interna nachfragen. Folgender Sachverhalt

• Webpart / Lösung wird eingespielt => Lösung funktioniert, kann alle Website-Vorlagen lesen und verwenden und daraus Webseiten erstellen
• einen Tag später: die Funktion "Erstelle Website" meldet nur noch "Benutzer hat keine Zugriffsrechte..."; Berechtigungen haben sich aber nicht geändert
• Lösung funktioniert wieder wenn
   ~ ein IIS Reset erfolgt bzw. Application Pool recycled wird
   ~ die Lösung neu eingespielt wird
• einen Tag später funktioniert die Lösung wieder nicht

woran könnte das liegen?

Andi Fandrich Als Antwort am 25 Okt. 2013 09:13

Das kann Dir hier wahrscheinlich niemand sagen. Offenbar greifst Du auf irgendwas zu, das durch den nächtlichen App Pool Recycle ungültig wird. Seltsamerweise geht es dann aber wieder, wenn ein weiterer Recycle erfolgt.

Kannst Du hier relevante Codeausschnitte posten? Aber bitte nicht einfach viele hundert Zeilen Webpartcode - das liest keiner.

Peter Oswald Als Antwort am 25 Okt. 2013 09:17

könnte es so etwas ähnliches sein wie in

• http://stackoverflow.com/questions/12050619/sharepoint-webpart-property-disappear-after-a-day-c

dass die Verwendung von statischen Objekte, die instanzabhängig sind, und so ihre Zuordnung verlieren? Aber was ist dann der Unterschied zwischen aktivem IIS Reset und Recycling Application Pool über Nacht...?

Andi Fandrich Als Antwort am 25 Okt. 2013 09:38

Natürlich ist das das Problem. Wie kommst Du auf die Idee hier ein statisches Feld zu verwenden? Überlege mal was passiert, wenn das Webpart mehr als einmal verwendet wird!

Peter Oswald Als Antwort am 25 Okt. 2013 09:49

Auf die Idee kommt man, wenn man nebenbei noch Windows Forms Applications programmieren muss. Aber trotzdem danke für die Zurechtweisung.

Andi Fandrich Als Antwort am 25 Okt. 2013 14:33

Bein Windows Forms bekommst Du aber genau dasselbe Problem, wenn ein Form innerhalb der Anwendung mehrfach geäffnet werden kann (also nicht nur einmal als Dialog)...