6
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:
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
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:
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 614265
Url: https://administrator.de/contentid/614265
Ausgedruckt am: 23.11.2024 um 22:11 Uhr
6 Kommentare
Neuester Kommentar
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.
wohl ein Objekt obwohl es aber leer ist.
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.
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!
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.Sind nun doch schon knapp 30 Cmdlets und Unmengen an Methoden.
Gruß w.
2Zitat 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!
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.Sind nun doch schon knapp 30 Cmdlets und Unmengen an Methoden.
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.
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!
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 ...
1Zitat von @146189:
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 ...
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
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!
