Visualizador de relatório - Solicitação para a permissão do tipo SQLClientPermission

Question

Estou usando o Controle do ReportViewer do Visual Studio 2008 no modo local com objetos como fonte de dados. Minhas aulas são mapeadas para tabelas de dados no meu banco de dados. Nos objetos, ele carrega objetos relacionados, conforme necessário. Por isso, deixa a referência nula até você tentar usar a propriedade e, em seguida, ele tenta carregá -la do banco de dados automaticamente. As classes usam o espaço de nome System.data.sqlclient.

Quando interajo com os objetos no meu aplicativo Windows Forms, tudo funciona conforme o esperado. Mas quando passo o objeto a ser usado como fonte de dados de relatório e ele tenta carregar automaticamente o objeto relacionado, ele falha. O código cria um objeto SQLConnection e, quando eu chamo getCommand (), a seguinte exceção é lançada:

[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

Tentei procurar o erro, mas todos os resultados que aparecem são para montagens CLR em execução em um SQL Server ou ASP.NET. Tentei adicionar a chamada a seguir no meu código (conforme sugerido nos resultados da pesquisa) antes de criar os objetos SQLConnection, mas aparentemente não fez nada:

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

Alguma ideia?

Answer 1

Eu encontrei a solução. Você especifica system.security.policy.evidence de você executar a montagem (ou um que possui direitos suficientes) para o relato local para uso durante a execução.

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

Answer 2

Além da resposta do CUPPM. o ExecuteReportInCurrentAppDomain o método é depreciado desde o .NET4 e LocalReport.SetBasePermissionsForSandboxAppDomain deve ser usado em vez disso, pois o relatório é agora sempre executado no domínio da caixa de areia:

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

Veja detalhes aqui.

Answer 3

Caso alguém tropeça sobre isso como eu fiz enquanto procurava esse erro de permissão. Eu recebi esse erro usando um Windows-Forms-Aplicação Porque o cliente havia vinculado um atalho ao meu aplicativo-exe em sua máquina com " computername c $ application.exe" em vez de "C: Application.exe". - Isso causou a falha do sistema.

Ver http://www.duelec.de/blog/?p=236 Para maiores informações.

Answer 4

Uma nota de rodapé da resposta de Artem acima ...

Eu tive esse problema ao adicionar autenticação do Windows ao meu aplicativo ASP.NET. Framework de segmentação 4.5 e usando componentes de relatório 11. Quando eu estava permitindo que usuários anônimos (no Primeiro Dev) não tive problemas em usar o relatório. Assim que eu ativei o Windows Auth, eu obtiveria "#Error" sobre o agrupamento de expressões, ou não seria capaz de executar o relatório, dando a exceção listada acima.

Consegui contornar o problema, mas com uma versão ligeiramente modificada do que Artem postou. Não sei completamente o que o código faz além de um senso geral de que ele permite que o CAS confie no código do Sandboxed ReportViewer. Quaisquer comentários com uma pequena explicação seriam apreciados.

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

Answer 5

Um pensamento rápido, embora este não seja um erro que eu já vi, verifique se sua afirmação está no mesmo método que o código que está definindo a fonte de dados do recurso:

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

As afirmações de permissão não duram muito tempo, elas podem ser um problema de segurança; portanto, fazê -las o mais próximo possível do código que precisa deles provavelmente funcionará.