DLL dekompilieren und wieder einspielen

lapadula · Beiträge: 180 Erhaltene Danke: 10

Hallo

Bei einer Webforms-Webanwendung, für die es keinen Sourcode mehr gibt, muss ich einen Fehler beheben.
Ich habe eine DLL, in der in einer Klasse Queries für einen MSSQL Server zusammengebastelt werden. Ich möchte nun gerne wissen, was am Ende der Methode für eine Abfrage abgefeuert wird.
Ich habe mir überlegt, die DLL mit ILSpy und Reflexil zu bearbeiten und am Ende der Methode die Abfrage in eine Textdatei zu schreiben und auf C zu speichern.

Folgender Code wird injeziert:

markieren

C#-Quelltext

1:
2:
3:
4:

using (StreamWriter streamWriter = new StreamWriter("C:\\Debug.txt", true))
  {
    streamWriter.WriteLine(dbCommand.CommandText);
  }

Ich speichere die DLL mit den Änderungen ab und spiele diese on the fly in den Bin-Ordner ein.
Der Programminterne Logger (welcher Exceptions in eine Textdatei schreibt) gibt mir aber die folgenden Meldung aus:

Zitat:

ErrDescription="Could not load file or assembly 'System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified."

Ich ändere nur eine Methode in einer Klasse aus der DLL.

Die Usings sollten auch vollständig sein:

markieren

C#-Quelltext

1:
2:
3:
4:

using Microsoft.VisualBasic.CompilerServices;
using System;
using System.Data;
using System.IO;

Es kann gut sein, dass die DLL in VB geschrieben ist, ILSpy zeigt mir aber C# Code an, deshalb evtl. das using VisualBasic.CompilerServices. Das dürfte am Ende aber doch Egal sein, weil das Kompilat das selbe ist oder nicht.

Wenn ich die alte DLL wieder einspiele, funktioniert alles wieder.
Was muss ich hier noch beachten?

Moderiert von Th69: Quote-Tags hinzugefügt
Moderiert von Th69: Code-Tags hinzugefügt

Palladin007 · Verfasst: Di 27.11.18 14:53

Vorweg: C#.NET und VB.NET werden bei .NET beide zu CIL kompiliert.
Es macht also auch keinen Unterschied, als was Du nun den Code haben willst.
Es gibt zwar Klassen, die ein VisualBasic-Namespace haben, aber das sind am Ende auch nur normale .NET-DLLs und die sind CIL.

Ich hatte bei ILSpy aber schon Schwierigkeiten, dass das Projekt, was es mir ausgibt, nicht sauber erstellt. Ob sie das mittlerweile korrigiert haben, weiß ich nicht, jedenfalls nutze ich ILSpy nur zum Anschauen einer DLL.

Zum Bearbeiten verwende ich stattdessen DNSpy. Das Programm kommt schon hart an die Magie heran

Es kann dir eine DLL dekompilieren, Du kannst sie direkt bearbeiten und sogar debuggen. Es funktioniert manchmal etwas hackelig, aber bisher hab ich's immer irgendwie hin bekommen.
Wenn Du also nur eine kleine Änderung machen willst, kann das das Mittel der Wahl sein. Aber nicht vergessen: Backup machen

Dein Fehler wird aber vermutlich ein Anderer sein.
.NET lädt Abhängigkeit erst zur Laufzeit, wenn sie das erste Mal benötigt werden.
Wenn Du also das dekompilierte Projekt bearbeitest und kompilierst, könnte es sein, dass diese benötigte Abhängigkeit nicht im Output-Ordner neben der exe liegt. ILSpy kann dir ja auch nur das Projekt aus dem CIL-Code dekompilieren, sowas wie ein Build-Script kann es nicht kennen.

Das gleiche Problem hast Du aber auch bei DNSpy, nur dass Du da direkt im Porgamm-Ordner arbeiten kannst und dort für gewöhnlich die Abhängigkeiten noch vorhanden sind.

Ralf Jansen · Verfasst: Di 27.11.18 15:48

Wäre es nicht einfacher, wenn es dir nur um den CommandText geht, den am Serverende abzugreifen?

lapadula · Beiträge: 180 Erhaltene Danke: 10

Daran habe ich irgendwie nicht gedacht, danke Ralf

Momentan ist aber noch zu viel Traffic, so dass ich den Befehl da nicht fangen kann.

@Palladin007, danke für den Tip, ich schaue mir das Tool auf jeden Fall mal an, da ich es wohl öfters nutzen werde.

Ralf Jansen · Verfasst: Di 27.11.18 16:26

Zitat:

Momentan ist aber noch zu viel Traffic, so dass ich den Befehl da nicht fangen kann.

Der Sql Server Profiler kann ganz wunderbar nach Rechnername/Username/Appname/Datenbank etc. filtern.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme