Início / dba / Perguntas / 227619
Accepted
McNets
Asked: 2019-01-21 14:18:22 +0800 CST

Erro ao publicar a função SQLCLR C# usando o Visual Studio 2017

  • 772

Estou tentando (aprender) publicar uma função SQLCLR usando o Visual Studio 2017. (É uma função simples que envia um email.)

Como referência usei estes artigos sobre CodeProject e MSSQLTips :

Criar, executar, depurar e implantar a função SQL CLR com o projeto de banco de dados do Visual Studio 2013

Enviar email do SQL Server Express usando um procedimento armazenado CLR

Nas propriedades do projeto->SQLCLR eu configurei:

Permission level : UNSAFE

E de acordo com o artigo, atualizei os bancos de dados de destino:

sp_configure 'clr enabled', 1;  
GO  
RECONFIGURE;  
GO

E depois que recebi o erro, segui este conselho no artigo MSSQLTips:

Se você receber mensagens de erro ao tentar compilar o código, talvez seja necessário alterar o banco de dados usando o comando a seguir e tente novamente criar o assembly e o procedimento armazenado.

ALTER DATABASE msdb SET trustworthy ON

Eu tentei usar dois bancos de dados de destino diferentes:

  • SQL Server 2017 LocalDB
  • SQL Server 2017 Express

Consigo construir o projeto sem erros, mas quando publico o projeto recebo um erro ao executar o próximo comando:

CREATE ASSEMBLY [dbSysmac]
    AUTHORIZATION [dbo]
    FROM 0x5F8A900003000000...
    WITH PERMISSION_SET = UNSAFE;

(47,1): SQL72014: .Net SqlClient Data Provider: Msg 10327, Level 14, State 1, Line 1 CREATE ASSEMBLY para assembly 'dbSysmac' falhou porque assembly 'dbSysmac' não é confiável. O assembly é confiável quando uma das seguintes condições for verdadeira: o assembly é assinado com um certificado ou uma chave assimétrica que tem um logon correspondente com a permissão UNSAFE ASSEMBLY ou o assembly é confiável usando sp_add_trusted_assembly.

O que estou fazendo de errado?

sql-server c#

1 respostas

  1. Best Answer

    Atualizei os bancos de dados de destino: 

     sp_configure 'clr enabled', 1;

    Só para ficar claro, "clr ativado" e, sp_configureem geral, são configurações no nível da instância, não no nível do banco de dados.

    Eu segui este conselho no artigo MSSQLTips

    Caramba. Bem, esse artigo sobre MSSQLTips é mais um problema do que o erro que você está recebendo. Seria melhor se você esquecesse tudo o que viu nesse artigo e nunca mais olhasse para ele. Está cheio de maus conselhos:

    1. SQLCLR não é necessário para enviar e-mail no SQL Server Express (eu testei isso e funciona). NO ENTANTO, não funciona no SQL Server Express LocalDB :-(
    2. Você deve usar SqlStringem vez de Stringpara tipos de parâmetros de entrada (e para tipos de retorno)
    3. Implantando para msdb? Talvez seja apenas eu, mas eu nunca implantaria código para msdb(e só adicionaria código masterse for fisicamente necessário, como ao marcar um proc como um proc de inicialização ou como um proc do sistema).
    4. UNSAFEconjunto de permissões? Por quê? Para e-mail? A montagem deve ser EXTERNAL_ACCESS. O código (assemblies, logins, usuários ou qualquer outra coisa) não deve receber mais permissões do que o necessário.
    5. A configuração TRUSTWORTHY ONpara msdbé dois problemas em um:
      1. A configuração TRUSTWORTHY ONé preguiçosa. Claro, é bom fazer prova de conceito/testes rápidos, mas não é uma boa opção de longo prazo/nível de produção. É um grande risco de segurança. Em vez disso, a assinatura do módulo deve ser usada. Aqui está um guia que escrevi sobre como fazer isso e fazê-lo no Visual Studio:
        SQLCLR vs. SQL Server 2017, Parte 2: "CLR strict security" - Solução 1
      2. TRUSTWORTHYjá é ONpara msdb. Pelo menos é ONpor padrão.
    6. O @bodyparâmetro de entrada deve ser NVARCHAR(MAX), não NVARCHAR(4000). Este é, afinal, e-mail HTML (ou seja, myMessage.IsBodyHtml = True)
    7. Não, absolutamente não armazene sua senha de e-mail em texto simples no código .NET. DLLs/assemblies não são criptografados. TODAS as strings são armazenadas como estão no final do EXE / DLL / Assembly. Não é preciso quase nenhum esforço para exibir o conteúdo de um assembly e, se você seguir esse conselho, seu servidor SMTP, login e senha serão armazenados para que todos possam ver. Passe-os de uma variável ou faça uma consulta simples para selecionar em uma tabela. Você pode até conseguir obtê-los no Registro do Windows.

    Em qual banco de dados você está realmente publicando? Supondo que você esteja publicando em outro banco de dados que não seja msdb, então você, pelo menos de forma simplista, neste momento para avançar, precisa definir TRUSTWORTHY ONpara o banco de dados em que está publicando. Mas, novamente, a habilitação TRUSTWORTHYé apenas para teste (consulte: POR FAVOR, Por favor, pare de usar representação, TRUSTWORTHY e Cross-DB Ownership Chaining ).

    Agora, se você estiver executando o ALTER DATABASE...manualmente e ainda receber o erro ao publicar, provavelmente terá a opção "implantar propriedades do banco de dados" selecionada (no Visual Studio: vá para "Propriedades do projeto" | guia "Depurar" | "Opções de implantação " área para baixo). TRUSTWORTHYé uma dessas propriedades de banco de dados. Portanto, quando a opção "implantar propriedades do banco de dados" estiver marcada, cada implantação definirá as opções para corresponder ao que está definido no projeto. E por padrão, Trustworthynão está habilitado.

    Suas opções são:

    1. Se você estiver implantando propriedades de banco de dados:

      Para habilitar Trustworthyno Visual Studio (para implantações): vá para "Propriedades do Projeto" | guia "Configurações do projeto" | Botão "Configurações do banco de dados..." | guia "Diversos". Marque a caixa "Confiável" e clique no botão "OK".

    2. Se você não estiver implantando as propriedades do banco de dados:

      Habilite confiável no banco de dados em que você está implantando o assembly (habilitar TRUSTWORTHYnão msdbajudará)

    3. Depois de ter isso funcionando corretamente no desenvolvimento, lide com a segurança corretamente antes de enviar para a produção:

      SQLCLR vs. SQL Server 2017, Parte 2: "segurança estrita do CLR" - Solução 1

    Para saber mais sobre SQLCLR em geral, visite: SQLCLR Info . Certifique-se de verificar o link "Stairway to SQLCLR", que é uma série que estou escrevendo sobre este tópico no SQL Server Central.

    • 2

relate perguntas