Frage

Ich verwende die ReportViewer -Steuerung von Visual Studio 2008 im lokalen Modus mit Objekten als Datenquelle. Meine Klassen sind Datentabellen in meiner Datenbank zugeordnet. In den Objekten lädt es verwandte Objekte nach Bedarf. Daher bleibt die Referenz null, bis Sie versuchen, die Eigenschaft zu verwenden, und versucht sie dann automatisch aus der Datenbank. Die Klassen verwenden das System.data.sqlclient Namespace.

Wenn ich mit den Objekten in meiner Windows Forms -Anwendung interagiere, funktioniert alles wie erwartet. Wenn ich jedoch das Objekt übergeben soll, das als Berichtsdatenquelle verwendet werden soll und es versucht, das zugehörige Objekt automatisch zu laden, schlägt es fehl. Der Code erstellt ein SQLConnection -Objekt, und wenn ich GetCommand () aufrufe, wird die folgende Ausnahme ausgelöst:

[System.Security.SecurityException] {
"Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."
} System.Security.SecurityException

Ich habe versucht, nach dem Fehler zu suchen, aber alle Ergebnisse, die angezeigt werden, sind für CLR -Baugruppen auf einem SQL -Server oder ASP.NET gelten. Ich habe versucht, den folgenden Anruf in meinem Code hinzuzufügen (wie in den Suchergebnissen vorgeschlagen), bevor ich die SQLConnection -Objekte erstellt habe, aber es hat anscheinend nichts getan:

System.Data.SqlClient.SqlClientPermission(System.Security.Permissions.PermissionState.Unrestricted).Assert();

Irgendwelche Ideen?

War es hilfreich?

Lösung 2

Ich habe die Lösung gefunden. Sie spezifizieren system.security.policy.Evidence von Ihnen, die Versammlung (oder eine, die über ausreichende Rechte verfügt) an den örtlichen Bericht zur Verwendung während der Ausführung ausführte.

reportViewer.LocalReport.ExecuteReportInCurrentAppDomain(System.Reflection.Assembly.GetExecutingAssembly().Evidence);

Andere Tipps

Zusätzlich zur Antwort von CUPPM. Das ExecuteReportInCurrentAppDomain Methode ist veraltet, da .NET4 und LocalReport.SetBasePermissionsForSandboxAppDomain sollte stattdessen verwendet werden, da ReportViewer jetzt ist stets ausgeführt in sandboxed Domain:

PermissionSet permissions = new PermissionSet(PermissionState.None);
permissions.AddPermission(new FileIOPermission(PermissionState.Unrestricted));
permissions.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
ReportViewer1.LocalReport.SetBasePermissionsForSandboxAppDomain(permissions);

Siehe Einzelheiten hier.

Nur für den Fall, dass jemand darüber stolpert, wie ich es getan habe, um nach diesem Erlaubnis zu suchen. Ich habe diesen Fehler mit a Windows-Forms-Anwendung Weil der Kunde eine Abkürzung mit meiner Anwendung auf seinem Computer mit " Computername c $ application.exe" anstelle von "C: application.exe" verknüpft hatte. - Dies verursachte das Ausfall des Systems. Sicht der Zeitspanne aufgrund der nicht vertrauenswürdigen Intranet -Verwendung.

Sehen http://www.duelec.de/blog/?p=236 für mehr Informationen.

Eine Fußnote zu Artems Antwort oben ...

Ich hatte dieses Problem, als ich meine ASP.NET -App Windows -Authentifizierung hinzufügte. Targeting Framework 4.5 und Verwendung von Berichtskomponenten 11. Als ich anonyme Benutzer (in Early Dev) erlaubte, hatte ich keine Probleme mit dem ReportViewer. Sobald ich Windows Auth aktiviert habe, würde ich entweder "#Error" zum Gruppieren von Ausdrücken erhalten oder den Bericht überhaupt nicht ausführen, um die oben aufgeführte Ausnahme zu geben.

Ich konnte das Problem umgehen, aber mit einer leicht modifizierten Version dessen, was Artem veröffentlicht hat. Ich bin mir nicht ganz sicher, was der Code außer einem allgemeinen Sinn macht, dass CAS dem Sandbox -ReportViewer -Code vertrauen kann. Alle Kommentare mit einer kleinen Erklärung würden geschätzt.

    Dim permissions As PermissionSet = New PermissionSet(PermissionState.Unrestricted)
    myReportViewer.LocalReport.SetBasePermissionsForSandboxAppDomain(permissions)

Ein kurzer Gedanke, obwohl dies kein Fehler ist, den ich gesehen habe, stellen Sie sicher, dass sich Ihre Behauptung in derselben Methode befindet wie der Code, der die Ressourcendatenquelle festlegt:

System.Data.SqlClient.SqlClientPermission mPermission = new SqlClientPermission(System.Security.Permissions.PermissionState.Unrestricted);
try
{
    mPermission.Assert();
    //rest of your code
}
//Handle Exceptions

Die Erlaubnis behauptet nicht lange, sie können ein Sicherheitsproblem sein. Daher funktioniert es am wahrscheinlichsten, dass sie so nah wie möglich mit dem Code funktioniert, der sie benötigt.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top