SPTimerJob in VS C# - Haltepunkte & Execute Methode

Andi Fandrich Als Antwort am 17 Sept. 2015 09:49

Du hast das schon alles richtig verstanden und "nur" ein Problem mit dem Debuggen. Das ist bei Timerjobs auch ein bißchen komplizierter...

Am Besten entfernst Du nochmal die ganze Solution samt Feature und Timer und fängst von vorne an. Ich würde das auch lieber manuell machen und nicht durch Visual Studio. Man hat dann einfach einen besseren Überblick, was da vor sich geht.

Zuerst stellst Du die Solution bereit. Das kann man z.B. per PowerShell machen (Add-SPSolution). Anschließend muß die Solution noch bereitgestellt werden und das kann man im Browser in der Zentraladministration machen.

Die Solution kann jetzt benutzt werden und Du kannst das Feature bei den Webanwendungen aktivieren. Wenn Du diesen Prozeß (und damit den FeatureReceiver) debuggen möchtest, mußt Du Visual Studio manuell an den w3wp der Zentraladministration hängen. Wenn Du den eigentlichen Timer, also dessen Execute-Methode debuggen möchtest, mußt Du Dich an den owstimer hängen.

Wenn Du später die Solution updatest, mußt Du manuell in der Services-Konsole den Timerdienst neu starten. Und wie immer: Du darfst in Visual Studio nicht das kleinste Fitzelchen Code ändern, sonst wird die bereitgestellte Assembly als veraltet angesehen und läßt sich nicht mehr debuggen.

MStel Als Antwort am 17 Sept. 2015 12:07

Danke für deine Antwort.
Habe nun nochmal alles von neu begonnen, vorher die bestehende Lösung entfernt sogar die Anwendung gelöscht. Sämtliche SharePoint Dienste sowie IIS und PC mal sicherheitshalber neu gestartet.
Dann habe ich neu begonnen die Anleitung Schritt für Schritt nachzubauen. Ohne F5 zu drücken bin ich bei erstellen auf Paket gegangen und habe diese .wsp mithilfe von Powershell auf meine Zentraladministration hochgeladen und für die GAC bereitgestellt.
Anschließend habe ich in Visual Studio Haltepunkte in jeder Funktion des Eventreceivers und der Klassen gesetzt und bei Debug an den Prozess w3wp angehangen, welcher seltsamerweise 3x auftaucht in der Liste.
Dann bin ich bei dem Timer auf jetzt ausführen gegangen, allerdings springt VS immer noch nicht in einen der gesetzten Haltepunkte. (Der Debug Modus ist ja gestartet sobald ich auf An Prozess anhängen drücke, ab dann habe ich in VS nichts mehr gemacht)
Weil ich nicht sicher war, ob der richtige Prozess ausgewählt war habe ich anschließend das Debuggen beendet und den die restlichen w3wp ausprobiert - wieder erfolglos.
Zuletzt habe ich versucht in einen Haltepunkt zu kommen indem ich mich an den owstimer hänge, ebenfalls ohne Effekt.

 In Visual Studio geht es einfach nicht weiter, egal wie oft ich den Timer auszuführen versuche. Auch mit F5, F9, F11 lässt sich dort nicht weiterspringen.

Andi Fandrich Als Antwort am 17 Sept. 2015 12:32

Also warum das Debuggen nicht funktioniert, kann ich jetzt so aus der Ferne nicht sagen. Da sind mir jetzt die Ideen ausgegangen.

Aber noch ein paar Erklärungen:

Du hast soviele w3wp-Prozesse wie laufende Application Pools. In SharePoint also mindestens drei (Zentraladministration, "normale" Webanwendung und SP Webservices). Du mußt Dich dabei immer an den hängen, der Deinen Code ausführt. Oder an alle auf einmal, das geht auch.

Aktivieren bzw. Deaktivieren des Features läuft im Kontext der Zentraladministration, also deren w3wp. Das brauchst Du, wenn Du den FeatureReceiver debuggen möchtest. Der Timerjob selbst läuft im Kontext des SharePoint Timerdienstes, also owstimer. Das brauchst Du, wenn Du die Exceute-Methode Deiner SPJobDefinition debuggen möchtest.

MStel Als Antwort am 17 Sept. 2015 13:48

Ist die Reihenfolge meiner Durchführung denn richtig?
- Entwickeln der Klassen und hinzufügen des Feature Managers in C#
- Speichern und Packen
- Haltepunkte in sämtlichen Funktionen die überprüft werden wollen hinzufügen
- Hochladen der Wsp (PowerShell)
- Hinzufügen der Lösung 
- Debug starten, indem an Prozess anhängen ausgewählt wird
- Lösung bei Überwachung -> Zeitgeberaufträge suchen, "Jetzt ausführen"
- Wundern warum der Compiler nicht in den Haltepunkt springt

Bevor ich die Lösung wieder zurückziehen kann muss ich in Powershell "stsadm -o execadmsvcjobs" ausführen, was in der Fehlermeldung die erscheint wenn ich es ohne den Befehl versuche erklärt wird.

Andi Fandrich Als Antwort am 17 Sept. 2015 14:40

Erscheint da wirklich der Timerjob (Zeitgeberauftrag) gleich nach dem Hochladen und Bereitstellen der wsp? Normalerweise sollte dazu zuerst das Feature aktiviert werden. Kann es sein, daß Du da noch einen alten Timerjob hast?

MStel Als Antwort am 17 Sept. 2015 14:46

Seltsamerweise ja.

MStel Als Antwort am 17 Sept. 2015 15:16

Bekomme nun wenn ich die OWSTIMER.exe auswähle noch folgende Meldung:
Das Folgende Modul wurde entweder mit aktivierten Optimierungen oder ohne Debuginformationen erstellt:

C:\Windows\assembly\GAC_MSIL\ArchiveFilesJob\1.0.0.0_6e791e81eb96157c\ArchifeFilesJob.dll

Zum Debugging des Moduls verwenden sie als Projektbuildkonfiguration den Debugmodus. Um diese Meldung zu unterdrücken, deaktivieren sie die Debugoption "Beim Start warnen, wenn kein Benutzercode".

Andi Fandrich Als Antwort am 17 Sept. 2015 15:31

Stelle mal in Visual Studio die Build-Konfiguration auf Debug. Das geht mit dem DropDown oben, wo bei Dir jetzt wahrscheinlich Release steht.

MStel Als Antwort am 18 Sept. 2015 08:15

Das hatte ich schon auf debug stehen.
Den Fehler konnte ich beheben indem ich bei Debug -> Optionen und Einstellungen -> Nur eigenen Code verwalten deaktiviert habe