mayho33
Goto Top

C-Sharp CmdLet - Richtiger Aufbau

Hallo @ All

Ich habe eine Frage zu C# (eigentlich Powershell-Cmdlets die in C# erstellt wurden) und hoffe auf eure Hilfe, weil ich aktuell immer wieder Probleme mit den CmdLets habe, wenn sie als SYSTEM ausgeführt werden.

Mein CmdLet hat mehrere Funktionen für die Installation via SCCM. Die wichtigsten sind Logging (mit NLog als Grundlage), MSI und EXE-Installation/Deinstallation.

Die Cmdlets funktionieren eigentlich immer, wenn man sie interaktiv verwendet, sprich, wenn ein Benutzer angemeldet ist und man in dessen Session arbeitet. Der Import meiner DLL erfolgt in der PS1 mit Import-Modul:
posershell_user

Als SYSTEM ausgeführt, z.B. via PSEXEC.exe in der CMD bekomme ich aber, manchmal den Fehler "Objekt-Verweis wurde nicht auf die Objekt-Instanz festgelegt"

Kann mir jemand sagen warum dieser Fehler auftritt? Ich habe bereits alle Verweise geprüft und aufgelöst. Überall sind explizite Verweise vorhanden.

Danke für eure Hilfe!

Mayho

Content-ID: 614265

Url: https://administrator.de/contentid/614265

Printed on: October 4, 2024 at 03:10 o'clock

146189
146189 Oct 19, 2020 updated at 08:50:09 (UTC)
Goto Top
Kapsele sämtlichen Code mit try catch und lass die Exceptions und Variableninhalte inkl. Codezeile in eine Datei loggen dann siehst du wo dein Fehler im Code liegt. Verständlich das man hier so ohne vorliegenden Code leider nur Vermutungen anstellen kann, gerade bei dem sehr sehr generellen Fehler der so gut wie auf alles passt. Offensichtlich benutzt du
wohl ein Objekt obwohl es aber leer ist.
mayho33
mayho33 Oct 19, 2020 at 08:53:09 (UTC)
Goto Top
Zitat von @146189:

Kapsele sämtlichen Code mit try catch und lass die Exceptions inkl. Codezeile in eine Datei loggen dann siehst du wo dein Fehler im Code liegt.

Gute Idee! Werde ich alsbald versuchen!

Verständlich das man hier so ohne vorliegenden Code leider nur Vermutungen anstellen kann, gerade bei dem sehr sehr generellen Fehler der so gut wie auf alles passt. Offensichtlich benutzt du wohl ein Objekt obwohl es aber leer ist.

Ja, ich weiß! Ich wollte aber nicht gleich 3000 Zeilen Code hier einstellen, weil ich ja nicht weiß wo genau der Fehler auftritt. Sind nun doch schon knapp 30 Cmdlets und Unmengen an Methoden.

Grüße!
146189
Solution 146189 Oct 19, 2020 updated at 09:16:51 (UTC)
Goto Top
weil ich ja nicht weiß wo genau der Fehler auftritt
Genau dafür hat man ja den Debugger geschaffen 😁
Ich wollte aber nicht gleich 3000 Zeilen Code hier einstellen,
Sind nun doch schon knapp 30 Cmdlets und Unmengen an Methoden.
Und du erwartest nun das das unsere Glaskugeln deinen Code erschnüffeln können 🙈? Das ist dann doch zu viel Erwartungshaltung, da musst du dann selber durch.

Gruß w.
mayho33
mayho33 Oct 19, 2020 updated at 09:46:05 (UTC)
Goto Top
Zitat von @146189:

weil ich ja nicht weiß wo genau der Fehler auftritt
Genau dafür hat man ja den Debugger geschaffen 😁

Ja! Der war gut! face-wink Im Debugging funktioniert alles Super! Wäre es so einfach, hätte ich den Fehler vermutlich gefunden. Auch wenn man "nicht" als SYSTEM arbeitet läuft alles zu 100%. Das macht es ja so schwierig, denn nur eben, wenn man als SYSTEM arbeitet (SCCM macht das so), dann haut's manchmal, "eben nur manchmal" nicht hin. Wie oben schon beschrieben.

Mir wäre keine Möglichkeit bekannt als SYSTEM, ohne Profil zu debuggen.

Ich wollte aber nicht gleich 3000 Zeilen Code hier einstellen,
Sind nun doch schon knapp 30 Cmdlets und Unmengen an Methoden.
Und du erwartest nun das das unsere Glaskugeln deinen Code erschnüffeln können 🙈? Das ist dann doch zu viel Erwartungshaltung, da musst du dann selber durch.

Nein! Das erwarte ich natürlich nicht. Eher habe ich gehofft, dass jemand so firn ist in PS bzw C#, dass er weiß warum PS im System-Account sowas von anders reagiert und gibt sein Wissen weiter. Höchstwahrscheinlich habe ich selbst wo einen Fehler eingebaut. Davon gehe ich einfach mal aus. Ist halt nicht so easy komplett ohne Hinweis einen Fehler zu finden. face-wink

Ich baue mal überall ein Try-Catch ein und logge das raus, wie du geschrieben hast. So komme ich sicherlich auf einen grüne Zweig.

Grüße!
146189
146189 Oct 19, 2020 updated at 10:40:21 (UTC)
Goto Top
Zitat von @mayho33:
Mir wäre keine Möglichkeit bekannt als SYSTEM, ohne Profil zu debuggen.
So wie man einen Windows-Dienst debuggt man hängt den Debugger an den jeweiligen Prozess: https://www.c-sharpcorner.com/article/debugging-windows-services-in-C-Sh ...
mayho33
mayho33 Nov 02, 2020 at 11:26:22 (UTC)
Goto Top
Zitat von @146189:

Zitat von @mayho33:
Mir wäre keine Möglichkeit bekannt als SYSTEM, ohne Profil zu debuggen.
So wie man einen Windows-Dienst debuggt man hängt den Debugger an den jeweiligen Prozess: https://www.c-sharpcorner.com/article/debugging-windows-services-in-C-Sh ...

Ich glaube du verstehst mich falsch. Ich erstelle und debugge das CMDLET als DLL in Visual-Studio (C#). Dazu hänge ich bereits einen Prozess an "Project => Settings => Debug => External Program = powershell.exe" + Arguments = -executionpolicy bypass -file <meine.ps1>

Der Vorteil: Haltepunkte in Code, OnTheFly-Änderungen

Da ist kein Platz mehr für einen zweiten Process face-wink Aber ich löse es nun anders. Anstatt die powershell.exe anzuhängen, hänge ich psexec.exe ein und verlege alles andere zu den Arguments.
Also so: "Project => Settings => Debug => External Program = psexec.exe" + Arguments = -s powershell.exe -executionpolicy bypass -file <meine.ps1>

Je nach CPU-Konfiguration und #Directive das eine oder das andere.

Mit psexec.exe verliere ich zwar die Möglichkeit mit Haltepunkten zu arbeiten, aber ich muss nicht ständig das Modul laden und entladen um zu testen ob es überhaupt funktioniert im SYSTEM-Context.

Grüße!