Ich kann nicht verstehen, wie man CA2123 für ein C ++ / CLI-Projekt repariert. Hier ist ein Beispielprojekt, um das Problem zu demonstrieren:
1) Erstellen Sie eine C # (.NET 4) Klassenbibliothek
ManagedClass.cs
Namespace CSharpLibrary {
%Vor%}
2) Erstellen Sie eine C ++ / CLI-Konsolenanwendung (VS 2010):
AssemblyInfo.cpp
%Vor%CPlusPlusCLIConsoleApp.h
%Vor%CPlusPlusCLIConsoleApp.cpp
%Vor%Nachdem ich alle Microsoft-Sicherheitsregeln aktiviert habe, erhalte ich folgende Warnung:
CA2123 Override Link Anforderungen sollten identisch mit Base
seinFügen Sie das folgende Sicherheitsattribut hinzu 'MainClass :: WriteSomething (void)', um ein LinkDemand anzugleichen Basismethode 'IManagedClass :: WriteSomething (void)': 'SecurityCriticalAttribute'.
CPlusPlusCLIConsoleApp cpluspluscliconsoleapp.cpp 13
Ich habe versucht zu folgen, was diese StackOverflow Antwort vorgeschlagen hat, aber es hat nicht behoben Fehler.
Ich verstehe, dass die verwaltete DLL standardmäßig SecurityCritical ist (ich möchte das in meinem ursprünglichen Projekt nicht ändern), da ich kein SecurityAttribute angegeben habe. Warum folgt die C ++ CLI-DLL nicht demselben Standard?
Welche Schritte sollte ich befolgen, um diesen Fehler zu beheben? (Grundsätzlich wie kann ich WriteSomething Methode SecurityCritical in C ++ CLI machen)
EDIT 1: Ich habe die gleiche Frage auf MSDN .
BEARBEITEN 2: Hat sich mit Microsoft in Verbindung gesetzt. Das C ++ \ CLI-Team hatte gerade keine Zeit, Level2 Security für C ++ \ CLI zu implementieren. Daher bleibt C ++ \ CLI immer bei Level1 Security hängen. Man kann die Codeanalysewarnung für dasselbe sicher unterdrücken.
Das Grundproblem besteht darin, dass Ihre C # - und C ++ - Assemblys zwei verschiedene Transparenzmodelle verwenden (siehe Ссылка und Ссылка für Details zu den zwei Ebenen. Das liegt daran, dass die C # -Assembly standardmäßig auf Ebene 2 kompiliert wird, aber die C ++ - Assembly vom Compiler aus einem scheinbar undokumentierten Grund automatisch auf die Ebene 1 gezwungen wird. Leider scheint das letztere Verhalten nicht zu übersteuern. Um die Dinge noch schlimmer zu machen, scheint es in VS2012 nicht geändert zu haben, und es sieht nicht so aus, als ob das Produktteam in Erwägung zieht, es bald zu ändern .
Da Sie die C ++ - Assembly nicht auf Ebene 2 verschieben können, gibt es einige potenziell sinnvolle Optionen, wenn Sie die ausführbare Datei in C ++ behalten möchten und die Schnittstellenimplementierung enthalten muss:
Reproduzieren Sie die "Eskalation" der Sicherheitskritikalität der Stufe 2 auf "voll" Vertrauen Link / Vererbung Nachfrage über die Verwendung von PermissionSetAttribute. z.B.:
%Vor%Es könnte sich auch lohnen, einen weiteren Fehlerbericht über Connect zu senden (das Abstimmen für geschlossene scheint es nicht zu tun) sehr nützlich sein) oder eine Feature-Anforderung für UserVoice , um die Änderung des Compiler-Verhaltens anzufordern. (Locking in Level 1 ist ziemlich seltsam, da Level 2 der Standard für .NET 4.0 und höher ist.)
Tags und Links .net .net-4.0 c++-cli code-access-security