Vamos a um cenário nada comum: Você tem uma DLL VB6 compilada para 32-bits, lógico!

Ela é utilizada no Banco de Dados e está no COM+.

A DLL VB6 é usada pelo banco de dados SQL Server 2000 e agora queremos um SQL Server 2008 R2 num SO de 64 bits.

E A DLL VB6 que estava lá? Não vai dar pra migrar!

Calma!! É simples resolver esse tipo de problema. O que nós precisamos é isolar o seu problema. Você precisa de uma máquina rodando rodando um SO de 32 bits, seja ele qual for.

A forma mais simples seria reescrever em uma DLL CLRSQL, claro. Mas muitas vezes não temos todo o tempo hábil para fazer isso, a DLL VB6 pode conter procedimentos muito críticos e específicos que não podemos perder.

Vamos seguir o seguinte diagrama para resolver o problema: A DLL rodando sob um serviço .Net, usando o serviço como um proxy para acessar a DLL, e o consumo dessa DLL que antes era feito direto, usando sp_OAcreate, é feito no SQL Server 2008, usando um function (ou procedure) CLRSQL conectando no serviço.

O serviço serviria como uma “casca” para isolar o acesso à DLL VB, e no futuro “matá-la por inanição”, ou seja, migrando aos poucos o código VB para a “casca” .Net e quem sabe no futuro para a própria DLL CLRSQL.

Vamos Começar

Preparando o Banco de dados

O Primeiro passo é bem simples: Vamos preparar o Banco de dados para aceitar uma DLL CLRSQL que possa se conectar em um webservice.

Passos:

1. Faça os procedimentos para subir o nível de compatibilidade, habilitar o CLRSQL (não vou entrar em detalhes)
2. No banco master, conectado como DBA, dê grant para assembly não-seguras

   USE master
   -- Outro usuário precisa dar esse grant
   GRANT UNSAFE ASSEMBLY TO <login>
   GO
   -- SET TRUSTWORTHY ON is not recommended but we will use anyway
   ALTER DATABASE TIA SET TRUSTWORTHY ON
   reconfigure
   GO
   

3. No Server Manager, em features, instale o .Net Framework 3.5.1 (não precisa instalar os recursos adicionais como WAS, somente o framework mesmo)
4. Copiar o Gacutil. O Gacutil é uma ferramenta importante, auxilia no registro de DLL’s no GAC. Ela vai estar presente no Windows SDK (http://www.microsoft.com/en-us/download/details.aspx?id=24826). Você vai precisar apenas dos arquivos gacutil.exe e gacutil.exe.config.
5. Registre no GAC, utilizando o Gacutil.exe as seguintes DLL’s  (o caminho pode ser diferente dependendo da versão do SO do servidor) “gacutil.exe -i <caminho>”:

6. C:\Windows\Microsoft.NET\Framework64\v3.0\Windows Communication Foundation\SMDiagnostics.dll

   C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll

   C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Messaging.dll

   C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.IdentityModel.dll

   C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.IdentityModel.Selectors.dll

   C:\Windows\Microsoft.NET\Framework64\v3.0\Windows Communication Foundation\Microsoft.Transactions.Bridge.dll

   C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.DirectoryServices.AccountManagement.dll

7. Registrar no SQL Server essas mesmas dependências, na ordem listada:

   --Exemplo:
   CREATE ASSEMBLY
   [System.Messaging] FROM
   'C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Messaging.dll'
   WITH permission_set = UNSAFEGO
   

8. O ambiente já está preparado para aceitar DLL’s CLR SQL

Desenvolvendo a CLRSQL

[[Em breve… Estou montando o ambiente para colocar os detalhes… ]]

Criando um serviço para consumir a DLL VB6

[[Em breve… Estou montando o ambiente para colocar os detalhes… ]]

Abraços!  E até a próxima!

• ← Enterprise Library – Alterando fonte de conexão de dados
• Tudo dinâmico no código! Mas nem tudo… →