Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Überschreiben einer virtual Methode aus einer anderen DLL
CSharpFreak
myCSharp.de - Member



Dabei seit:
Beiträge: 42

Themenstarter:

Überschreiben einer virtual Methode aus einer anderen DLL

beantworten | zitieren | melden

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
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von CSharpFreak am .
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

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)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16145

beantworten | zitieren | melden

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 - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
unconnected
myCSharp.de - Member

Avatar #avatar-3200.jpg


Dabei seit:
Beiträge: 862
Herkunft: Oerlinghausen/NRW

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

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)
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1516
Herkunft: Düsseldorf

beantworten | zitieren | melden

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. ;)
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Palladin007 am .
private Nachricht | Beiträge des Benutzers
CSharpFreak
myCSharp.de - Member



Dabei seit:
Beiträge: 42

Themenstarter:

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von CSharpFreak am .
private Nachricht | Beiträge des Benutzers
t0ms3n
myCSharp.de - Member



Dabei seit:
Beiträge: 319

beantworten | zitieren | melden

Was heißt denn erweitern? Vielleicht helfen dir auch Extension Methods weiter!?
private Nachricht | Beiträge des Benutzers
MarsStein
myCSharp.de - Experte

Avatar #avatar-3191.gif


Dabei seit:
Beiträge: 3430
Herkunft: Trier -> München

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16145

beantworten | zitieren | melden

Zitat von CSharpFreak
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 - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
pinki
myCSharp.de - Member

Avatar #avatar-4072.jpg


Dabei seit:
Beiträge: 704
Herkunft: OWL

beantworten | zitieren | melden

Mal rein Interesse halber: Was soll denn zu welchem Zweck erreicht werden?
private Nachricht | Beiträge des Benutzers