Hallo -
ich habe ein Problem und zwar möchte ich gerne eine Methode die wie folgt deklariert ist überschreiben:
internal virtual void DoSome(Object X)
{
}
Sie befindet sich allerdings in einer eigenen Assembly. Ist das überschreiben mit Hilfe von Reflektion möglich?
Mir geht es darum, dass ich an den Parameter 'X' heran komme, um ihn anschließend modifizieren zu können.
MfG
internal bedeutet ja automatisch, dass die Methode nur innerhalb der Assembly der deklarierenden Klasse verwendet wird. Mit anderen Worten kannst du sie ja nicht einmal "von draußen" aufrufen. Insofern ergibt deine Anforderung eigentlich überhaupt keinen Sinn...
Machbar ist es dennoch, aber nur mit erheblichem Aufwand bei zweifelhaftem Sinn. Schau dir mal PostSharp an.
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Was genau ist denn das Ziel?
Ich kenne keine Anforderung, bei der das legitim wäre, sondern nur für Schadsoftware.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Für PostSharp müsste er die Assembly selber kompilieren. Ich vermute das ist nicht ganz was er will.
Mit Reflection Emit müsste das gehen. Ausprobiert habe ich es aber noch nicht.
Lesetipp: Blogeintrag zum Thema, und was an der Anforderung von CSharpFreak falsch ist.
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Wenn Du als Zugriffsmodifier sowohl internal als auch protected verwendest, dann ist die Methode in der eigenen Assembly und in ableitenden Klassen jeder anderen Assembly zugreifbar.
Ein anderer Weg ist, wenn Du eine zweite Methode schreibst, die protected virtual ist und in der ersten Methode aufgerufen wird. Z.B.:
internal void Work()
{
// Mach was anderes
DoWork();
// Mach noch etwas anderes
}
protected virtual void DoWork()
{
// ...
}
Ob das per Reflection möglich ist - eher nicht
Man könnte sich aber die Position heraus suchen, wo der IL-Code der Methode im RAM liegt und dann diese Position verändern. Sprich: Du tauschst den IL-Code der Methode aus.
Das geht, hab ich aus Interesse schon gemacht, ist aber mit erheblichen Aufwand verbunden, sehr fehleranfällig und ganz sicher das schlechteste, was Du dir als Lösung raus suchen kannst. 😉
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Vielen Dank erst einmal für die zahlreichen Antworten!
Ich möchte keine Schadsoftware basteln... Es geht mir lediglich darum eine bereits vorhandene Assembly zu erweitern ohne sie nachbauen zu müssen.
An dem tauschen des IL-Codes hab ich auch schon gedacht, dass ist ja generell immer möglich... Ich dachte jedoch das es dafür eine bessere Möglichkeit gibt. Ich denke mal, dass ich einen kompletten Rework der Klasse machen werden.
Was heißt denn erweitern? Vielleicht helfen dir auch Extension Methods weiter!?
Hallo,
ich halte so eine Herangehensweise, nicht-öffentliche Codekonstrukte aus anderen Assemblies anzuprogrammieren, nicht nur für generell falsch, sondern auch für hochgradig gefährlich.
Die gehören nämlich eben gerade nicht zur öffentlichen Schnittstelle, weshalb weder deren Existenz noch die Konsistenz deren Funktionsweise gewährleistet sind.
Mit anderen Worten: Es könnte Dir mit jedem Servicepack/Update des Frameworks passieren, dass sich da was geändert hat und Dein Code schlichtweg nicht mehr funktioniert oder im schlimmsten Fall üble Seiteneffekte hervorruft.
Gruß, MarsStein
Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca
Ich möchte keine Schadsoftware basteln... Es geht mir lediglich darum eine bereits vorhandene Assembly (von M$) zu erweitern ohne sie nachbauen zu müssen.
Allein die Bezeichnung M$ disqualifiziert Dich in jeder Hinsicht, Dich ernst zu nehmen. Das nur am Rande.
Assemblies von .NET zu erweitern - und das gerade im Umbruch von .NET - ist alles andere als eine zielführende Idee.
Jeder der das liest: macht es blos nicht nach. Und gerade die Idee eine System-DLL zu verändern, wo Du gar nicht weißt, wer sie alles verwendet: geht unter Garantie nach hinten los.
Wie gesagt; die Idee alleine wäre reif fürs Gruselkabinett.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Mal rein Interesse halber: Was soll denn zu welchem Zweck erreicht werden?