Você precisa colocar um sqlservr.exe.config arquivo no \Binn pasta da pasta raiz dessa instância. Por exemplo:
C:\Arquivos de Programas\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn
Se você estiver usando o SQL Server 2008 R2 (SP1) ou mais recente, poderá encontrar o local exato por meio da consulta a seguir, que mostra o caminho completo para sqlservr.exe :
SELECT [filename] FROM sys.dm_server_services WHERE servicename LIKE N'SQL Server (%';
No seu código, você precisa desta linha no topo:
using System.Configuration;
E então isso vai funcionar:
[SqlFunction(DataAccess = DataAccessKind.None, IsDeterministic = true)]
public static SqlString GetConfig(SqlString WhichOne)
{
ConfigurationManager.RefreshSection("connectionStrings");
return ConfigurationManager.ConnectionStrings[WhichOne.Value].ToString();
}
Conteúdo do sqlservr.exe.config Arquivo:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="Stuff" connectionString="Trusted_Connection=true; Enlist=false;" />
<add name="ClrTest" connectionString="boo hoo" />
</connectionStrings>
</configuration>
É importante observar que, conforme indicado no link "Usando uma configuração de aplicativo...", as alterações feitas no arquivo de configuração não estão disponíveis imediatamente. ENTÃO , você não precisa forçar um recarregamento executando um dos métodos mencionados nesse artigo (ou seja,
DBCC FREESYSTEMCACHE e reiniciando o SQL Server). Tudo o que é necessário para obter informações atuais é recarregar a seção específica que você está usando via ConfigurationManager.RefreshSection(string sectionName) conforme mostrado no exemplo acima. Veja a nota abaixo sobre uso e desempenho. Recursos:
- Usando System.Configuration.dll em .NET sprocs e UDFs
- Usando um arquivo de configuração de aplicativo (app.config/web.config) na integração CLR do SQL Server
Além disso, a menos que seja absolutamente necessário, você não deve criar seu assembly como
UNSAFE . Se você está apenas tentando fazer conexões TCP com outras máquinas, isso deve exigir apenas EXTERNAL_ACCESS . USO E DESEMPENHO
Conforme sugerido por Joe B em um comentário abaixo, há um pequeno impacto no desempenho da
RefreshSection Operação. Se o código que contém a atualização for chamado mais de uma vez a cada dois minutos, ele poderá ter um impacto perceptível (um impacto desnecessário devido à falta de frequência de alteração de um arquivo de configuração). Nesse caso, você desejará remover a chamada para RefreshSection do código que é chamado com frequência e trata a atualização de forma independente. Uma abordagem seria ter um procedimento armazenado SQLCLR ou uma função escalar que apenas faça a atualização e nada mais. Isso pode ser executado sempre que uma alteração for feita no arquivo de configuração.
Outra abordagem seria descarregar o App Domain que recarregará o arquivo de configuração na próxima vez que qualquer objeto SQLCLR nesse banco de dados for referenciado. Um método bastante simples para recarregar todos os domínios de aplicativo em um banco de dados específico (mas não em toda a instância) é inverter o
TRUSTWORTHY configurando Ligado e Desligado novamente, ou Desligado e Ligado novamente, dependendo do estado atual dessa configuração. O código abaixo verificará o estado atual dessa configuração e a inverterá de acordo:IF (EXISTS(
SELECT sd.*
FROM sys.databases sd
WHERE sd.[name] = DB_NAME() -- or N'name'
AND sd.[is_trustworthy_on] = 0
))
BEGIN
PRINT 'Enabling then disabling TRUSTWORTHY...';
ALTER DATABASE CURRENT SET TRUSTWORTHY ON;
ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;
END;
ELSE
BEGIN
PRINT 'Disabling then enabling TRUSTWORTHY...';
ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;
ALTER DATABASE CURRENT SET TRUSTWORTHY ON;
END;
Por favor não use nenhum dos métodos mais drásticos --
DBCC FREESYSTEMCACHE , desabilitando e habilitando o clr enabled configuração do sistema, reiniciar a Instância, etc -- pois quase nunca é necessário fazê-lo. Especialmente reiniciando a Instância, ou DBCC FREESYSTEMCACHE que descarta todos dados em cache para toda a instância, o que afeta muito mais do que apenas SQLCLR. ATUALIZAÇÃO SOBRE O SQL SERVER NO LINUX
O SQL Server está agora, a partir da versão 2017, disponível no Linux (woo hoo!). No entanto, parece que a leitura do arquivo de configuração do aplicativo não trabalhar em Linux. Eu tentei muitas combinações de
sqlservr.exe.[Cc]onfig e sqlservr.[Cc]onfig , etc, e afins e não consegui nada para funcionar. Especificar um arquivo de configuração não pode funcionar, pois requer EXTERNAL_ACCESS permissão e apenas SAFE Assemblies são permitidos no Linux (a partir de agora, pelo menos). Se eu encontrar uma maneira de fazê-lo funcionar, postarei os detalhes aqui. 
