Ich habe eine (C#) Funktion ähnlich der folgenden.SecurityException: ECall-Methoden müssen in ein Systemmodul gepackt werden
private static bool SpecialCase = false;
public void Foo()
{
if (SpecialCase)
{
InternalMethod();
return;
}
Console.WriteLine();
}
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern void InternalMethod();
Wenn ich das mit dem .NET Framework 4 innerhalb des Debugger ausführen, druckt das Verfahren erfolgreich leere Zeile auf die Konsole und kehrt zurück. Wenn ich es außerhalb des Debugger ausführen, wirft es eine Ausnahme mit der folgenden Meldung:
System.Security.SecurityException: ECall methods must be packaged into a system module.
Es scheint die Ausnahme ausgelöst wird, wenn die JIT-Compiler die Methode im Gegensatz zu kompiliert, wenn (falls) InternalMethod genannt wird. Gibt es irgendetwas, was ich tun kann (z. B. Attribute), um der CLI zu sagen, dass sie entweder die SecurityException nicht auslöst oder die Ausnahme solange verzögert, bis die Methode tatsächlich aufgerufen wird?
Seitliche Anmerkung zum Anwendungsfall: Das Feld SpecialCase ist effektiv falsch, wenn es mit Microsoft .NET Framework ausgeführt wird, und wahr, wenn es unter einer anderen (spezifischen) CLI-Implementierung ausgeführt wird. Wenn Sie unter Microsoft .NET Framework ausführen, ist der Aufruf an InternalMethod effektiv nicht erreichbar.
Können Sie es in einer normalen Methode umhüllen? – SLaks
Ja, es scheint, dass der Aufruf einer Wrapper-Methode wie die folgende die Ausnahme vermeidet. Der Nachteil ist, dass diese Praxis zu noch verwirrenden Codepfaden in einem bereits komplexen Algorithmus führen würde. Daher bevorzuge ich eine sauberere Lösung, wenn eine gefunden wird. 'private static void InternerMethodWrapper() {InternalMethod(); } ' –
BTW Es passiert auch auf' .NET 4.5.2' aber in beiden Frameworks (beide Frameworks hat die gleiche 'CLR' sowieso) nur in 'Release' nicht in' Debug', haben Sie in Betracht gezogen, im 'Debug'-Modus zu arbeiten ? –