CIL: „Operation konnte die Laufzeit destabilisieren“ Ausnahme

Question

Ich habe mit Postsharp ein bisschen zu spielen und ich lief in ein unangenehmes Problem.

Im Anschluss an IL in Silverlight assembly:

.method public hidebysig specialname newslot virtual final instance void 
set_AccountProfileModifiedAt(valuetype [mscorlib]System.DateTime 'value') cil managed
{
    .maxstack 2
    .locals (
        [0] bool ~propertyHasChanged,
        [1] bool CS$4$0000)
    L_0000: nop 
    L_0001: nop 
    L_0002: ldarg.0 
    L_0003: call instance valuetype [mscorlib]System.DateTime 

Accounts.AccountOwner::get_AccountProfileModifiedAt()
    L_0008: ldarg.1 
    L_0009: call bool [mscorlib]System.DateTime::op_Inequality(valuetype 

[mscorlib]System.DateTime, valuetype [mscorlib]System.DateTime)
    L_000e: stloc.0 
    L_000f: ldarg.0 
    L_0010: ldarg.1 
    L_0011: stfld valuetype [mscorlib]System.DateTime 

Accounts.AccountOwner::accountProfileModifiedAt
    L_0016: br.s L_0018
    L_0018: ldloc.0 
    L_0019: ldc.i4.0 
    L_001a: ceq 
    L_001c: stloc.1 
    L_001d: ldloc.1 
    L_001e: brtrue.s L_002b
    L_0020: ldarg.0 
    L_0021: ldstr "AccountProfileModifiedAt"
    L_0026: call instance void 

Accounts.AccountOwner::NotifyPropertyChanged(string)
    L_002b: nop 
    L_002c: leave.s L_002e
    L_002e: ret 
}

löst System.Security.VerificationException: Operation die Laufzeit destabilisieren könnte. Ausnahme. Reflektor parst es OK. Was daran falsch sein könnte?

Update 1 Code soll wie folgt funktionieren:

public void set_AccountProfileModifiedAt(DateTime value)
{
    bool propertyHasChanged = this.AccountProfileModifiedAt != value;
    this.accountProfileModifiedAt = value;
    if (propertyHasChanged)
    {
        this.NotifyPropertyChanged("AccountProfileModifiedAt");
    }
}

Update 2 Ich bekomme angegebene Ausnahme in dem Setter selbst

Update 3 Herstellung von nicht-statische Anrufe als callvirt (NotifyPropertyChanged) nicht helfen

Update 4 Kommentiert aus (zu Testzwecken) Code:

L_0018: ldloc.0 
L_0019: ldc.i4.0 
L_001a: ceq 
L_001c: stloc.1 
L_001d: ldloc.1 

und L_001e ersetzt: brtrue.s L_002b mit L_001e: bs L_002b funktioniert der Trick, aber es ist eine bedingungslose Rückkehr - nicht, was ich will

.

Aktualisieren 5 Wenn ich C # Compiler verwenden erforderliche Verhalten zu imitieren (Ich brauche immer noch, dass mit Postsharp zu tun) Ich erhalte folgende IL:

.method public hidebysig specialname newslot virtual final instance void 

set_AccountProfileModifiedAt(valuetype [mscorlib]System.DateTime 'value') cil managed
{
    .maxstack 2
    .locals init (
        [0] bool val,
        [1] bool CS$4$0000)
    L_0000: nop 
    L_0001: ldarg.0 
    L_0002: call instance valuetype [mscorlib]System.DateTime 

Accounts.AccountOwner::get_AccountProfileModifiedAt()
    L_0007: ldarg.1 
    L_0008: call bool [mscorlib]System.DateTime::op_Inequality(valuetype 

[mscorlib]System.DateTime, valuetype [mscorlib]System.DateTime)
    L_000d: stloc.0 
    L_000e: ldarg.0 
    L_000f: ldarg.1 
    L_0010: stfld valuetype [mscorlib]System.DateTime 

Accounts.AccountOwner::accountProfileModifiedAt
    L_0015: ldloc.0 
    L_0016: ldc.i4.0 
    L_0017: ceq 
    L_0019: stloc.1 
    L_001a: ldloc.1 
    L_001b: brtrue.s L_0029
    L_001d: ldarg.0 
    L_001e: ldstr "AccountProfileModifiedAt"
    L_0023: call instance void 

Accounts.AccountOwner::NotifyPropertyChanged(string)
    L_0028: nop 
    L_0029: ret 
}

Hinweis gibt es geringfügige Unterschiede - extra bs springen bei L_0016 und einige seltsame Sprung L_001e: brtrue.s L_002b. In Compiler Version erhalte ich direkten Sprung zu ret.

Answer 1

Haben Sie verwenden PEverify? Sie sollten immer dieses Dienstprogramm ausführen, wenn sie direkt mit MSIL spielen (Sie können die msbuild Flagge / p verwenden: PostSharpVerify = true).

Mit Blick auf Ihrem Code ein:

1. Ihre lokalen Variablen nicht (fehlende "init" Schlüsselwort) initialisiert. Dies ist eine Eigenschaft von MethodBodyDeclaration.

2. Sie verwenden ein ‚verlassen‘ anstelle eines ‚JMP‘ aus einem geschützten Block; dies ist nutzlos, aber sollte keine Rolle spielen.

Viel Glück,

-gael

Answer 2

Es ist schwer zu sagen - haben Sie einen Stack-Trace haben? Diese Ausnahme wird in der Regel ausgelöst, wenn die CLR ist nicht in der Lage, die Art-Sicherheit des Codes zu überprüfen. Da dies aus diesem Code stammen könnte oder aus einem der Verfahren oder Typen, die Sie verwenden, es wird schwierig sein, zu sagen, was das Problem ohne einen Stack-Trace ist.

Answer 3

Hier einen Beitrag, der mit diesem Fehler befaßt. Ich weiß nicht, ob Ihr spezieller Fall durch das gleiche Problem verursacht wird, aber im Allgemeinen sieht es aus wie dieser mit Codezugriffssicherheit und Überprüfung zu tun hat. Wenn das der Fall ist, wird Reflector Lage sein, die IL zu lesen ganz gut, aber das CAS-System wird es aus unbekannten Gründen zu.

Es sieht aus wie Sie eine Eigenschaft Setter in einen Haufen von anderen Objekten aufrufen haben. Sie sollten die anderen Methodenaufrufe durch für große Switch-Anweisungen suchen, falls es das spezifische Thema im Beitrag erwähnt ist.