Desenvolvimento de banco de dados - Introdução de novos recursos na edição de banco de dados do VSTS GDR

Artigo
09/07/2015

Este artigo foi traduzido por máquina.

Desenvolvimento de banco de dados

Introdução de novos recursos na edição de banco de dados do VSTS GDR

Jamie Laflen and Barclay Hill

Este artigo discute:

Desenvolvimento de esquemas offline
Alterações de arquitetura de produto
Introdução a projetos de servidor
Suporte de projeto de SQL CLR

Este artigo usa as seguintes tecnologias:
O VSTS 2008 Database Edition GDR

Conteúdo

Desenvolvimento de esquemas offline
Administração de banco de dados
Alterações de arquitetura de produto
Introdução a projetos de servidor
Referências de projeto de servidor
Referência para objetos de nível de servidor compartilhadas
Referência de objetos do sistema
Atualização de projeto
Novo projeto de banco de dados criar e implantar
Instalação de linha de comando — VSDBCmd
Suporte de projeto de SQL CLR
Aprimoramentos de análise de código estático
Tips e truques

Em novembro de 2008, a versão de distribuição geral (GDR) para o Microsoft Visual Studio Team System 2008 (VSTS) banco de dados Edition foi lançado. O GDR instala em relação a versão inicial do VSTS 2008 Database Edition, mas ele é mais do que uma atualização de versão secundária. O GDR adiciona suporte ao SQL Server 2008, incorpora os aprimoramentos para recursos existentes, inclui muitos recursos novos e pontos de extensibilidade e incorpora recursos que foram lançados anteriormente como ferramentas de energia.

Neste artigo, vamos nos concentrar especificamente em Realce novos recursos no GDR, incluindo seu suporte para desenvolvimento de esquema off-line, ferramentas que oferecem suporte a novos processos que você pode usar ao desenvolver um esquema de banco de dados e recursos que oferecem suporte a administração de banco de dados.

Além desses aperfeiçoamentos de processo, o VSTS Database Edition GDR também fornece os seguintes recursos:

Interpretação e avaliação de esquema e interdependências do seu projeto. Processamento off-line permite que os desenvolvedores capturar erros de sintaxe e referência anteriores à implantação.
Refatoração — usando o VSTS Database Edition, você pode alterar o nome de um objeto (como uma tabela ou coluna), e essa alteração será atualizada todas as referências para o novo nome.
Automatizada diferenciação mecanismo — quando você implantar um projeto, ele gera um script do Transact-SQL (T-SQL) que contenha apenas as alterações necessárias para tornar o banco de dados destino coincidir com a fonte.
Testes de unidade de banco de dados — você pode usar um designer que permite o desenvolvimento de testes de T-SQL-orientado a para o exercício e verifique se o esquema antes como a verificação no seu código.
Testar a geração de dados — você pode usar essa ferramenta para gerar dados de teste realista pseudo-aleatória que podem ser usados quando você executar testes de unidade.

Juntamente com descrições dos recursos esses recursos fornecem, você encontrará alguns exemplos práticos que mostrá-los em ação.

Desenvolvimento de esquemas offline

Historicamente, desenvolvimento de esquema do banco de dados tem necessário escrever código contra um servidor de desenvolvimento compartilhado e, em seguida, escrever scripts de atualização para migrar as alterações de um ambiente para outro. Essa abordagem não fornece alguma maneira de controlar e mesclar as alterações aos objetos de banco de dados, que faz alterações de movimentação de um ambiente para outro um processo muito manual.

No VSTS Database Edition, objetos (tais como tabelas, procedimentos armazenados e modos de exibição) que compõem o esquema são gerenciados em um projeto de banco de dados do Visual Studio como scripts de CREATE. Armazenar esses objetos como scripts significa que você pode gerenciar os scripts através de um sistema de controle de código fonte e permite que mais de um desenvolvedor de banco de dados editar os scripts simultaneamente e mesclá-los conforme apropriado ao verificar alterações. O processo de editar arquivos de script sem estar conectado a um banco de dados é conhecido como desenvolvimento de esquemas offline. Depois que a definição de seu banco de dados foi movida de um banco de dados ao vivo para um ambiente off-line/modelado, os desenvolvedores de bancos de dados podem aplicar práticas de desenvolvimento ágil ou iterativa que fez desenvolvimento de aplicativos leaner e menos caro.

Um desenvolvedor de banco de dados pode começar a desenvolver off-line, criando um projeto de banco de dados no Visual Studio e, em seguida, importar o banco de dados de desenvolvimento atual para o projeto. O projeto importado pode aumentar alguns avisos, mas após limpar os avisos e o projeto cria com êxito, você pode verificá-lo para seu sistema de controle código fonte.

Depois que o código fonte e de projeto foram verificadas no, os desenvolvedores de sua equipe podem recuperar o código fonte e de projeto e trabalhar com eles em seus computadores locais. As alterações agora podem ser implantadas em um banco de dados local seguro e manualmente testados. Essa abordagem permite que um desenvolvedor trabalhar em isolamento sem introduzir instabilidade em um ambiente de banco de dados compartilhado. Você pode refinar essa abordagem, escrevendo um ou mais testes de unidade de banco de dados para verificar uma alteração. Depois que uma alteração foi verificada, executar todos os os testes de unidade no banco de dados seguro, que verifica não que código somente o modificado, mas também que a alteração não interromper qualquer outro código. Depois de passar os testes, verificar as alterações no sistema de controle de código fonte.

Quando as alterações tenham sido verificadas em e a equipe estiver pronta, uma compilação pode ser executada Obtendo a fonte do sistema de controle de código fonte. Depois de criado, o banco de dados, em seguida, pode ser implantado com código do aplicativo em um ambiente no qual os usuários podem começar a trabalhar com o produto recém-desenvolvido.

Administração de banco de dados

O VSTS Database Edition fornece várias ferramentas que facilitam a tarefas comuns que você executa ao você administrar um banco de dados. Uma dessas ferramentas é comparar do esquema, que automatiza a tarefa de comparação e atualizar esquemas. Você pode usar o esquema comparar para comparar dois bancos de dados e, em seguida, gerar um script de atualização para criar, alterar ou descartar objetos no banco de dados de destino. Se alterações precisam fique diretamente para um banco de dados ao vivo fora o processo de implantação normal, você pode usar o esquema comparar para comparar um banco de dados com um projeto de banco de dados offline e, em seguida, importar todas as atualizações novamente para o projeto de banco de dados para ser verificado no controle de código de origem.

A ferramenta Comparar do esquema tem um número de novos recursos no GDR. Visíveis a maioria dos é sua capacidade de manter as configurações de comparação e opções entre as sessões de uso. (Comparação resultados não são salvas, apenas as opções e configurações.)

A capacidade de manter as configurações e opções apresenta um novo tipo de arquivo para o sistema de projeto, o arquivo de .scmp, que é armazenado na pasta comparação de esquema do sistema do projeto por padrão. Vários arquivos de comparação de esquema podem ser criados e salvos no projeto. Você também pode salvar seu without de configurações de esquema comparar um projeto de banco de dados para manter configurações de comparação que você usa com freqüência para solução de problemas ou outros motivos operacionais.

Comparar do esquema agora também fornece configurações de opção de nível de sessão que podem ser acessadas a barra de esquema comparar ferramentas, mostrada na Figura 1 . Você pode filtrar objetos para excluir tipos de objeto específico de comparações, variáveis SQLCMD definidas em seus projetos podem ser substituídas para comparações e opções de script podem ser definidas que controlam como o script de atualização é criado. Essas opções podem ser salvos em um arquivo .scmp.

Figura 1 opções de comparação de esquema

A barra de ferramentas Comparar esquema fornece fácil navegação entre cada diferença de esquema em uma comparação. Você pode filtrar para tipos de diferenças para o novo modo de exibição, ausentes, diferentes, igual ou uma combinação desses tipos. Comparação de esquema também suporta comparando arquivos .dbschema. Agora você pode comparar qualquer combinação de um projeto, o banco de dados e o arquivo .dbschema. Atualizações de escrita se o destino for que um arquivo .dbschema não é possível com esta versão, mas todas as outras combinações oferecem suporte a comparação e gravar as atualizações em um destino.

O VSTS Database Edition também fornece uma ferramenta que facilita comparar os dados em dois sistemas de banco de dados. Usando o Data Compare, um administrador pode comparar tabelas que têm chaves primária/exclusiva e detectam onde os dados ausentes, adicionais ou diferentes existe nos dois sistemas. Como comparar de esquema, a Data Compare pode gerar um script que irá escrever atualizações diretamente para o sistema de destino para tornar dados de seus dados correspondência o sistema de origem.

Alterações de arquitetura de produto

O GDR apresenta uma série de alterações de arquitetura chaves. Uma das mais significativas é uma representação verdadeira modelo de bancos de dados do SQL Server.

Nas versões anteriores do VSTS Database Edition, uma instância de projeto do SQL Server 2005 era necessária. O sistema de projeto usado a instância de design como uma etapa de validação final para scripts DDL (Data Definition Language) no projeto do banco de dados. Isso necessário cada desenvolvedor tem uma instância do SQL Server executando localmente em sua própria área de trabalho ou criar máquinas para criar uma representação offline do banco de dados.

Com o GDR, a instância de design não é mais necessária e o sistema de projeto é suportado por uma representação totalmente modelada do esquema do banco de dados. O GDR cria o modelo que representa o banco de dados do SQL Server dos scripts DDL em seu projeto de banco de dados e fornece o modelo para todas as ferramentas de banco de dados que estão disponíveis no Visual Studio. Compilar o projeto de banco de dados produz um arquivo de .dbschema que é uma representação XML serializada do modelo. Implantação de um projeto de banco de dados gera um script de implantação que se baseia uma comparação de saída de compilação do projeto com o modelo criado a partir de banco de dados de destino.

Entre sessões do uso do projeto, o modelo do projeto de banco de dados é mantido em um arquivo .DBML sob o diretório raiz do projeto. O arquivo .DBML fornece um cache do modelo para acelerar a abertura e criação de projetos de banco de dados existentes que têm esquemas maiores.

Modelos são implementados por provedores de esquema do banco de dados (DSPs). O GDR inclui três DSPs, um para cada versão com suporte do SQL Server, SQL Server 2008, bem como o SQL Server 2000 e o SQL Server 2005, como nas versões anteriores. Com um modelo baseado em provedor, versões do VSTS Database Edition agora são dissociados das versões do SQL Server. Quando uma nova versão do SQL Server é lançada ou um service pack atualiza uma versão existente com nova funcionalidade ou a sintaxe, um novo ou atualizado DSP possa ser lançado para suportar essas alterações no funcionalidades do SQL Server. Em futuras versões do Visual Studio Team System, esse modelo baseado em provedor permitirá terceiros estender suporte de ambiente de projeto o VSTS Database Edition para outras plataformas de banco de dados.

Introdução a projetos de servidor

Projetos de servidor, um novo recurso fornecido pelo GDR, permitem uma equipe definir uma configuração de nível de servidor para seus bancos de dados do SQL Server em um projeto autônomo. O objetivo principal de um projeto de servidor é compartilhar uma configuração esperada e objetos entre projetos de banco de dados. Um projeto de servidor pode ser referenciado por vários projetos de banco de dados sem duplicar as definições de objetos de servidor. Por exemplo, você pode ter três projetos de banco de dados, cada um representando um banco de dados usuário em seu servidor de destino. Cada um desses projetos de banco de dados deve ter uma referência para o mesmo projeto de servidor para garantir que a configuração do servidor de banco de dados de destino seja consistente.

As configurações de configuração de servidor definidas em um projeto de servidor são usadas para fins de verificação durante a implantação, embora nenhuma alteração real será feita na configuração do servidor no momento da implantação. Durante a implantação, a configuração do servidor é verificada para coincidir com a configuração esperada descrita o projeto de servidor. Se a verificação da configuração falhar conforme especificado no projeto de servidor, implantação falhará e nenhuma alteração é feita a objetos de nível de servidor compartilhados ou bancos de dados do usuário.

Para configurar o servidor em um projeto de servidor, você fazer alterações para o arquivo de Server.sqlsettings encontrado na pasta de propriedades do projeto de servidor. (Você pode consultar manuais online do SQL Server para a versão do SQL Server você está usando para obter uma descrição de que cada configuração de servidor.) Um exemplo das configurações do servidor é mostrado na Figura 2 .

A Figura 2 exemplos de configurações do servidor para um Project Server

Por padrão, nenhuma configuração de servidor é verificadas durante a implantação. Para ter uma configuração verificada durante a implantação, marque a caixa de seleção Verificar e configurar o valor esperado na coluna Value.

Referências de projeto de servidor

Objetos nos projetos de banco de dados que fazem referência a objetos de nível de servidor requerem os objetos de nível de servidor a ser definido. Modelagem de objetos de nível de servidor em um projeto de servidor permite que você faça referência a esses objetos dos seus projetos de banco de dados. Por exemplo, se seu projeto de banco de dados define um usuário com um logon, você precisará criar um projeto de servidor para modelar o logon de nível de servidor que é exigido pelo usuário em seu projeto de banco de dados. Se você estiver usando apenas objetos do sistema e não têm objetos de nível de servidor compartilhados, você pode simplesmente adicionar uma referência para o arquivo master.dbschema que é instalado com o GDR.

Referência para objetos de nível de servidor compartilhadas

Projetos de servidor fornecem suporte para a modelagem de objetos de nível de servidor compartilhados, que têm um comportamento diferente e escopo de objetos de banco de dados-nível de usuário. Referências de objeto de nível de servidor inválido por objetos no banco de dados projetos são sinalizados e controladas revertidas para o projeto de servidor, com cada não resolvida referência indicada por erros ou avisos.

Um exemplo comum de um objeto de nível de servidor compartilhado é um logon. Vários bancos de dados de usuário podem use o mesmo logon ao definir objetos de usuário em projetos de banco de dados referenciando o objeto de logon em um projeto de servidor. Se você tiver os objetos de usuário definidos em seus projetos de banco de dados que fazem referência a um logon, você deve estabelecer uma referência banco de dados a um projeto do servidor onde existe o logon com o objeto de usuário resolver totalmente em seu projeto de banco de dados. Caso contrário, você receberá um erro de validação semelhante àquele mostrado na Figura 3 .

A Figura 3 um exemplo de um erro de validação

Para fazer referência a objetos em um projeto de servidor, primeiro crie um projeto de servidor que representa o banco de dados mestre. O projeto de servidor é criado de um modelo de projeto de servidor que pode ser encontrado no nó projetos de banco de dados da caixa de diálogo New Project. Há três modelos de projeto servidor, um para cada versão com suporte do SQL Server. Se o servidor de destino já existir, você poderá importar banco de dados mestre do destino servidor em um novo projeto de servidor. Quaisquer objetos definidos pelo usuário no servidor serão importados. Em seguida, crie o projeto de servidor para verificar se nenhum problema existe e criar um arquivo .dbschema que modela o servidor.

Em seu projeto de banco de dados, você pode referenciar o projeto de servidor ao estabelecer uma nova referência de banco de dados. No exemplo a seguir, tenho um projeto de servidor (meu_servidor) e um projeto de banco de dados (MyDatabase) na mesma solução. Crie uma referência de banco de dados clicando com o botão direito do mouse a pasta de referências de banco de dados do projeto MyDatabase no Solution Explorer e clicando em Adicionar referência de banco de dados. Você verá a caixa de diálogo Mostrar na Figura 4 .

A Figura 4 O Add Database Reference Dialog Box

Para esse tipo de referência, você deve aceitar as configurações de padrão apresentadas a caixa de diálogo Add Database Reference. Usando o mestre literal permite que seus objetos de banco de dados (como um procedimento armazenado) objetos de referência que existem no banco de dados do mestre (como uma tabela) incluindo o literal mestre como parte do nome de três partes. Se você tivesse unresolved erros de referência para objetos de nível de servidor, eles devem ser corrigidos pela nova referência. Figura 5 mostra as referências de banco de dados para o projeto MyDatabase no Solution Explorer depois que a referência é criada.

A Figura 5 as referências MyDatabase

Referência de objetos do sistema

Uma referência a um banco de dados mestre também é necessária se seu projeto de banco de dados usa objetos do sistema. Um exemplo de um objeto do sistema é um procedimento armazenado do sistema, tabela de sistema, o modo de exibição de sistema ou catálogo do sistema. Um objeto do sistema usado com freqüência em bancos de dados do usuário é o modo de exibição sysobjects. Por exemplo, verifique o procedimento armazenado mostrado na Figura 6 , que usa os modos de sistema sys.sysobjects e sys.schemas. Sem uma referência a um banco de dados mestre que contém as definições desses objetos, vários avisos são produzidos, indicando que os objetos de sistema usados no procedimento armazenado não podem ser resolvidos. Como procedimentos armazenados permitir resolução de nomes adiada, eles são avisos de referência não resolvidos. Essa mesma instrução SELECT em uma definição de VIEW pode produzir erros.

A Figura 6 avisos e erros ocorrem sem uma referência ao aMaster banco de dados

Para remover esses avisos, você deve criar uma referência para um banco de dados mestre que contém as definições desses objetos. No entanto, fazendo referência a objetos do sistema não requer um projeto de servidor. Lembre-se, projetos de servidores contêm os objetos e as configurações de você ter definidas. Para fazer referência a um banco de dados mestre contendo objetos do sistema, você referenciar um arquivo master.dbschema para resolver referências a objetos do sistema. Para criar uma referência para o arquivo master.dbschema, definir uma referência de banco de dados da mesma maneira como anteriormente apresentados, mas em vez de referência a um projeto, fazem referência a um arquivo .dbschema. Os arquivos master.dbschema podem ser encontrados nos seguintes diretórios:

"%programfiles%\Microsoft Visual Studio 9.0\VSTSDB\Extensions\SqlServer\
<SQL Version>\DBSchemas"

Há sete arquivos .dbschema instalados com o GDR, dois para cada versão com suporte do SQL Server e um arquivo de dbschema adicionais para o novo tipo de SQL disponíveis no SQL Server 2008.Observe que cada versão com suporte do SQL Server tem master.dbschema correspondente e os arquivos de msdb.dbschema.Também vale a pena observar que quando você cria as referências a arquivos master.dbschema, o modelo do seu projeto demore um pouco enquanto atualizar porque esses arquivos .dbschema contêm todos os objetos definidos no mestre banco de dados da versão do SQL Server está direcionando.Por fim, também é possível ter uma referência a um projeto de servidor e uma referência a um arquivo estático master.dbschema porque eles têm finalidades diferentes.Ambas as referências usaria o literal mestre.

Atualização de projeto

Se você estiver trabalhando com um projeto criado em uma versão do VSTS Database Edition antes para o GDR, você precisará mover os objetos de nível de servidor criado nos scripts de pré e pós-implantação para um novo projeto de servidor.Durante o processo de atualização de projeto, qualquer objeto de servidor definido nos scripts de pré e pós-implantação será movido para um arquivo de script denominado Upgraded.AllServerObjects.sql, que é colocado em uma subpasta da pasta do projeto raiz chamada atualização.Você pode importar esse arquivo de script em um projeto de servidor recém-criado usando o comando Importar script.Para resolver os erros de referência ou avisos, crie uma referência de seu projeto de banco de dados ao seu novo projeto de servidor.

Novo projeto de banco de dados criar e implantar

Quando você pensa sobre a implantação do banco de dados, alguns cenários imediatamente vêm à mente:

A maioria dos grupos de TI da têm vários ambientes que uma compilação de um aplicativo departamental deve percorrer antes de alcançarem o ambiente de produção e os usuários finais.
Fornecedores de software tenha um esquema de banco de dados de destino em mente quando eles lançar uma atualização, mas desejam normalmente atualizar o esquema de um cliente que pode não coincidir com esquema a versão anterior.

Esses cenários eram difíceis de gerenciar em versões anteriores do VSTS Database Edition porque um script de implantação T-SQL foi saído quando um projeto de banco de dados foi criado.A saída de compilação foi gerada por diferenciação o projeto de banco de dados e o banco de dados em à instância de destino (ou a instância de banco de dados do projeto) e, em seguida, escrever um script que pode atualizar a instância de destino para "aparência" fonte do projeto.Porque o script foi gerado em tempo de compilação, não havia uma maneira para fazer a saída de uma "compilação" e executá-la várias vezes em diferentes ambientes (com esquemas diferentes potencialmente).

Em GDR, as ações executadas durante a criação e implantação foram alterados para suporte melhor os cenários que descrevi.Em um alto nível, uma compilação agrega o conteúdo do projeto e gera um conjunto de arquivos que representar logicamente um pacote de implantação.Implantação consome os arquivos de "pacote de implantação", gera um plano de implantação e, em seguida, executa o plano gerando um script T-SQL.Você também pode configurar a implantação para aplicar esse script em relação ao banco de dados de destino.Como nas versões anteriores, criar e implantar estão disponíveis como tarefas do MSBuild e podem ser usadas no servidor de compilação de uma equipe.

Para oferecer suporte a implantação de uma compilação em diversos ambientes, informações de configuração orientado a implantação são acrescentadas em arquivos diferentes.Embora o uso de vários arquivos adicione alguns complexidade, ele permite colocar as configurações usadas ao implantar em diferentes ambientes sob controle do código-fonte.Para fazer isso concreto, vamos examinar um exemplo, mostrado na Figura 7 , na qual que deseja implantar uma versão do nosso projeto do banco de dados em quatro ambientes diferente.

A Figura 7 Exemplo de ambientes

Ambiente	Configuração de implantação
Desenvolvimento	Implantações a esse ambiente sempre recriar o banco de dados.Essa é a configuração de projeto de depuração.Variáveis de SqlCmd personalizados.
Integração	Implantações são diferenciação, onde instruções ALTER e quedas são geradas para objetos que não existem no projeto.Essa é a configuração de projeto de lançamento.Variáveis de SqlCmd personalizados.
Teste de usuário	Preparação para implantação do produto.Implantações são diferenciação.Variáveis de SqlCmd personalizados.
Produção	Implantações são diferenciação.Variáveis de SqlCmd personalizados.

Com base nesses quatro ambientes, podemos definir quatro arquivos de configuração de implantação personalizada e arquivos de SqlCmd, cada armazenar a configuração para o ambiente específico que se destinam ao destino.Depois de configurar esses arquivos, propriedades aparência do projeto de Figura 8 .

A Figura 8 Configurar propriedades do projeto para a implantação personalizada

Com os arquivos, você pode ver que eu tenha definido o arquivo Development.sqldeployment seja a configuração padrão da configuração de projeto de depuração.Da mesma forma, o arquivo de Development.sqlcmdvars é a definição padrão para variáveis de SqlCmd e valores.

Após um projeto é criado com êxito, a saída de compilação pode ser usada para implantar várias instâncias de banco de dados.A mesma saída de compilação pode ser usada para implantar um novo banco de dados ou para atualizar um banco de dados existente.Como você viu anteriormente, uma implantação por padrão será usar configuração do projeto quando o projeto foi criado; no entanto, você pode substituir qualquer uma das propriedades .deploymanifest na linha de comando.Por exemplo, para implantar a todos os ambientes que na Figura 8 , você usaria os seguintes argumentos de linha de comando:

Development:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Development.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Development.sqlcmdvars /p:TargetConnectionString=
   "DataSource=DEV\sql2008;Integrated Security=true;Pooling=false"

Integração:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Integration.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Integration.sqlcmdvars /p:TargetConnectionString=
    "DataSource=INT\sql2008;Integrated Security=true;Pooling=false"

Teste de usuário:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\UserTest.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\UserTest.sqlcmdvars /p:TargetConnectionString=
   "DataSource=USERTEST\sql2008;Integrated Security=true;Pooling=false"

Produção:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Production.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Production.sqlcmdvars /p:TargetConnectionString=
   "DataSource=PRODUCTION\sql2008;Integrated Security=true;Pooling=false"

Esses exemplos utilize a tarefa de implantação MSBuild para implantar uma versão do EnterpriseDB.dbproj em vários ambientes usando configurações diferentes. Você pode executar o mesmo tipo de implantação usando uma nova ferramenta de linha de comando que fornecido como parte do GDR, chamado VSDBCmd.

Instalação de linha de comando — VSDBCmd

O GDR vem com uma ferramenta de linha de comando chamada VSDBCmd (vsdbcmd.exe). Essa ferramenta pode criar um arquivo .dbschema de um banco de dados existente e implantar uma saída de compilação ou apenas um arquivo de .dbschema a uma instância de destino. VSDBCmd também pode ser usado em um computador em que o Visual Studio não está instalado. Para mover a ferramenta de linha de comando de um computador para outro, copie o executável e seus componentes da pasta Deploy sob o diretório VSTSDB. Em uma instalação padrão do Visual Studio, isso será "%ProgramFiles%\Microsoft visual studio 9.0\vstsdb\deploy\. O diretório de implantação pode ser copiado para um thumb-unidade e, em seguida, colocado em outro computador.

Apresentar VSDBCmd, vamos executar a ferramenta a partir da linha de comando. a Figura 9 mostra os resultados. Embora essas opções podem parecer complicadas à primeira vista, há vários pontos em mente que o ajudará a compreender como essas opções são agrupadas:

VSDBCmd é projetado para ser usado com várias plataformas de banco de dados. Hoje, o VSTS Database Edition oferece suporte somente SQL Server, mas isso provavelmente mudar em futuras versões.
Para importar um esquema de banco de dados ou implantar em um banco de dados, você precisará fornecer uma seqüência de conexão. Essa seqüência de conexão é uma seqüência de conexão padrão do ADO.NET para o provedor de banco de dados.
Como a ferramenta é independentemente de qualquer provedor de banco de dados específico, você precisará fornecer uma dica com relação à qual provedor deve ser usado com a seqüência de caracteres da conexão, e uma seqüência de conexão deve ser definida para determinar a versão de banco de dados que destino. Por exemplo, algumas opções para a implantação do SQL Server só estão disponíveis para SQL2005 e posterior.

A Figura 9 saída de VSDBCmd

>"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" /?
Help for dynamic property usage
/help[+|-]                        (short form /?)
/Action:{Import|Deploy}           (short form /a)
/ConnectionString:<string>        (short form /cs)
/DatabaseSchemaProvider:<string>  (short form /dsp)
@<file>                           Read response file for more options

Help for command actions
/Action:{Import|Deploy}           (short form /a)
/Quiet[+|-]                       (short form /q)
/ConnectionString:<string>        (short form /cs)
/DeployToDatabase[+|-]            (short form /dd)
/ModelFile:<string>               (short form /model)
/ManifestFile:<string>            (short form /manifest)
/DeploymentScriptFile:<string>    (short form /script)
/DatabaseSchemaProvider:<string>  (short form /dsp)
/Properties:<string>              (short form /p)
@<file>                           Read response file for more options

Para criar um modelo do banco de dados Northwind, pode executar o seguinte:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Import 
/cs:"Data Source=(local)\sql2008;Integrated Security=true;Initial Catalog=Northwind08" 
/dsp:sql 
/model:northwind.dbschema

Aqui eu indicar que que deseja criar um arquivo de .dbschema chamado northwind.dbschema do banco de dados especificado na seqüência de conexão. Como VSDBCmd oferece suporte a vários provedores, também deve especificar o provedor para usar ao criar o arquivo .dbschema, nesse caso, o provedor de "SQL". Como você pode ver, as opções para importar um banco de dados para um modelo são bastante simples. Há algumas opções de importação adicionais que são específicas para SQL Server. Para ver essas opções, você pode usar o seguinte comando de ajuda de propriedades dinâmicas:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Import 
/cs:"Data Source=(local)\sql2008;Integrated Security=true"
/dsp:sql 
/?

Agora podemos ativar ao redor e implantar o modelo que são importados para um novo banco de dados. Para implantar o modelo, use o seguinte comando:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/cs:"Data Source=(local)\sql2008;Integrated Security=true" 
/model:northwind.dbschema 
/dd:+  
/p:TargetDatabase=NewNorthwind

Este comando implanta o modelo contido northwind.dbschema para o \sql2008 de instância (local) e em um novo banco de dados chamado NewNorthwind. Quando VSDBCmd for executado sem a implantar a opção de banco de dados (/ dd: +), somente um script de implantação é gerado, que é muito semelhante ao script gerado por implantar um projeto ou usando o esquema comparar. No exemplo anterior, se (/ dd: +) não foi especificado, um script de comparação seria saída (porque nós não especificar um nome, o nome do arquivo seria northwind.txt). Isso pode ser uma boa maneira para gerar um script para verificação e analisar antes para executar o script à instância de destino.

A opção /p:TargetDatabase = NewNorthwind é diferente de outras opções. Ele é um exemplo das várias opções que são expostas através da estrutura de extensibilidade de ferramenta. Para ver todas as opções que estão disponíveis para SQL Server, use o seguinte comando em um banco de dados do SQL Server 2008:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/cs:"Data Source=(local)\sql2008;Integrated Security=true" 
/dsp:sql 
/?

Essas são as mesmas opções que estão disponíveis em vários implantação e esquema comparar páginas de configuração.

Bem como implantar um arquivo .dbschema, VSDBCmd também pode ser usado para consumir e implantar a saída de uma compilação de projeto do banco de dados. Você pode usar VSDBCmd para executar a mesma implantação multienvironment feita anteriormente com o MSBuild. No entanto, com VSDBCmd, você não precisará usar o arquivo .dbproj para executar a tarefa de implantação ou ter o VSTS Database Edition instalado. Nos exemplos a seguir, VSDBCmd é executado na pasta de saída de compilação:

Desenvolvimento:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Development.sqldeployment 
/p:SqlCommandVariablesFile=Development.sqlcmdvars 
/cs:"Data Source=DEV\sql2008;Integrated Security=true"

Integração:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Integration.sqldeployment 
/p:SqlCommandVariablesFile=Integration.sqlcmdvars 
/cs:"Data Source=INT\sql2008;Integrated Security=true"

Teste de usuário:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=UserTest.sqldeployment 
/p:SqlCommandVariablesFile=UserTest.sqlcmdvars 
/cs:"Data Source=USERTEST\sql2008;Integrated Security=true"

Produção:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Production.sqldeployment 
/p:SqlCommandVariablesFile=Production.sqlcmdvars 
/cs:"Data Source=PRODUCTION\sql2008;Integrated Security=true"

Nesses exemplos, você pode ver que VSDBCmd pode ser usado para implantar uma versão do seu projeto de banco de dados em vários ambientes usando configurações diferentes.

Suporte de projeto de SQL CLR

Desde o SQL Server 2005, os desenvolvedores tem tido a capacidade de implementar tipos, procedimentos, funções e disparadores como tipos CLR. Antes do GDR, usando esses tipos como parte do esquema de um projeto de banco de dados era difícil porque a saída de assembly pelo projeto C# ou Visual Basic tinha a ser adicionado como um script com texto codificado na base64. Com o GDR, suporte para projetos do SQL CLR bastante aumentou. Eles podem agora ativamente ser usados como parte do seu esquema de banco de dados em tempo de design e gerenciados em uma instância durante a implantação do projeto. Vamos examinar um exemplo para examinar como isso funciona.

Primeiro, criar uma solução e adicionar um projeto de banco de dados do SQL Server 2008. Em seguida, adicione um projeto de SQL CLR C# chamado CustomTypes, conforme mostrado na Figura 10 . Quando este projeto C# é adicionado, ele solicita um destino de implantação. Porque a implantação do assembly for a serem gerenciados pelo projeto do banco de dados, cancelar essa caixa de diálogo.

A Figura 10 adicionando um projeto de SQL CLR

Agora adicione uma referência do projeto de banco de dados para o projeto C#. Como referências de projeto C#, essa referência indica que o conteúdo do projeto referenciado está sendo usado pelo projeto referenciador. Adicione a referência com o botão direito do mouse no nó referências do projeto de banco de dados e, em seguida, clicando em Add Reference. Na caixa de diálogo Add Reference, selecione o projeto CustomTypes.

Embora a referência tiver sido adicionada, você ainda precise personalizar como ele está configurado para que ele for implantado corretamente. Para modificar a configuração do assembly, selecione a referência e, em seguida, pressione F4. a Figura 11 mostra o que você verá no navegador de propriedade.

A Figura 11 Definindo propriedades para CustomTypes

Neste exemplo, modifiquei AssemblyName para coincidir com o nome do projeto e AssemblyOwner explicitamente ser dbo. Por padrão, o nível de permissão do assembly é seguro. No entanto, você pode alterar essa configuração se você precisar implante o código não seguro para a instância do SQL Server.

Neste ponto, você pode implantar o assembly criado pelo projeto CLR CustomTypes selecionando implantar em propriedades do projeto do Database1. Como nós não tiver configurado uma seqüência de conexão para o projeto, ele gerará um script de implantação CREATE. Na janela de saída, você verá a saída mostrada na Figura 12 .

A Figura 12 Implantando o assembly CustomTypes

------ Build started: Project: CustomTypes, Configuration: Debug Any CPU ------
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig 
/nowarn:1701,1702 /warn:4 /define:DEBUG;TRACE /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.XML.dll /debug+ /debug:full 
/optimize- /out:obj\Debug\SqlClassLibrary.dll /target:library Properties\AssemblyInfo.cs

Compile complete -- 0 errors, 0 warnings
CustomTypes -> D:\Demos\Database1\CustomTypes\bin\Debug\SqlClassLibrary.dll
------ Build started: Project: Database1, Configuration: Debug Any CPU ------
    Loading project references...
    Loading project files...
    Building the project model and resolving object interdependencies...
    Validating the project model...
    Writing model to Database1.dbschema...
  Database1 -> D:\Demos\Database1\Database1\sql\debug\Database1.dbschema
------ Deploy started: Project: CustomTypes, Configuration: Debug Any CPU ------
Error: Cannot deploy. There is no database connection specified. To 
correct this error, add a database connection using the project properties.
Error: The operation could not be completed 
------ Deploy started: Project: Database1, Configuration: Debug Any CPU ------
    Deployment script generated to:
D:\Demos\Database1\Database1\sql\debug\Database1.sql

    The deployment script was generated, but was not deployed. You can 
    change the deploy action on the Deploy tab of the project properties.
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 1 failed, 0 skipped ==========

O projeto CustomTypes é citado pelo Database1, para que o Visual Studio tentou implantar o projeto antes de implantar Database1. Porque nós não fornecer uma seqüência de conexão para o projeto CustomTypes com, ele pode não ser implantado, que causou um erro. Nós pode ignorar este erro porque o assembly será ser implantado como parte do script de implantação Database1. É possível evitar esse erro, desativando a implantação do CustomTypes por meio do Gerenciador de configuração.

Depois de criar e implantar o projeto, você pode abrir o script de implantação Database1 e ver que o assembly é criado até o final do script:

GO
PRINT N'Creating CustomTypes...';

GO
CREATE ASSEMBLY [CustomTypes]
    AUTHORIZATION [dbo]
    FROM 0x4D5A90000300000004[snip…]    
    WITH PERMISSION_SET = SAFE;

GO

O conteúdo do assembly também é usado para verificar as referências de tipo em tempo de compilação. Para ver como isso funciona, adicione um tipo definido pelo usuário (UDT) ao projeto CustomTypes usando o modelo padrão. Chame esse arquivo Type1.cs. Para usar esse tipo no banco de dados, ele deve ser declarado no projeto de banco de dados. Para adicionar o tipo definido pelo usuário, clique com o botão direito do mouse Database1, clique em Add Item e, em seguida, use o modelo de tipo definido pelo usuário (CLR). Por padrão, o arquivo criado pelo modelo será o seguinte:

CREATE TYPE [dbo].[Type1]
  EXTERNAL NAME [assembly_name].[type_name]

Agora, modificar esse T-SQL para fazer referência Type1 em CustomTypes, assim:

CREATE TYPE [dbo].[Type1]
  EXTERNAL NAME [CustomTypes].[Type1]

Salvar este arquivo e procure na lista de erro. Você verá um erro semelhante ao seguinte:

TSD04117: The referenced type with the required Clr attribute was not found in the loaded 
assembly.

Este erro é exibido porque o projeto CustomTypes não foi criado desde que adicionamos Type1.cs. Reconstruir o projeto CustomTypes fará com que esse erro desapareça. Você pode usar esse tipo personalizado como uma coluna de tipo por adicionar a tabela a seguir ao projeto:

CREATE TABLE [dbo].[Table1]
(
  column_1 int NOT NULL, 
  column_2 dbo.Type1 NULL
)

Quando a tabela é adicionada ao projeto, a referência dbo.Type1 é avaliada pelo sistema do projeto e causará erros se dbo.Type1 não existir.

Bem como escrever um script de implantação, o projeto também pode ser implantado para uma instância de SQL 2008, como mostrado na Figura 13 . Quando o projeto é implantado para a instância de destino, o mecanismo de implantação detecta que o banco de dados precisa ser criado e o conteúdo do projeto é criado na ordem correta de dependência.

A Figura 13 Implantando o projeto CustomTypes

------ Build started: Project: CustomTypes, Configuration: Debug Any CPU ------
CustomTypes -> D:\Demos\Database1\CustomTypes\bin\Debug\SqlClassLibrary.dll
------ Build started: Project: Database1, Configuration: Debug Any CPU ------
    Loading project references...
    Loading project files...
    Building the project model and resolving object interdependencies...
    Validating the project model...
    Writing model to Database1.dbschema...
  Database1 -> D:\Demos\Database1\Database1\sql\debug\Database1.dbschema
------ Skipped Deploy: Project: CustomTypes, Configuration: Debug Any CPU ------
Project not selected to build for this solution configuration 
------ Deploy started: Project: Database1, Configuration: Debug Any CPU ------
    Deployment script generated to:
D:\Demos\Database1\Database1\sql\debug\Database1.sql

    Creating Database1...
    Creating CustomTypes...
    Creating dbo.Type1...
    Creating dbo.Table1...
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 0 failed, 1 skipped ==========

Aprimoramentos de análise de código estático

Antes para a versão do GDR, análise de código estático estava disponível através de uma ferramenta de energia. O GDR integrou a análise de código estático e fornece algumas alterações para o mecanismo de análise de código estático (SCA) que fez a sua execução mais flexível.

SCA agora pode ser executada como parte de cada compilação ou a partir da linha de comando usando MSBuild. Para forçar SCA para executar com cada compilação, alternar a opção Enable Code Analysis na seção de propriedades do projeto análise de código. Cada regra ou o grupo de regras pode ser tratado como um aviso (padrão) ou um erro. Regras SCA que localizar erros em seu projeto podem causar a compilação falhar e interromper a implantação. SCA avisos e erros podem também agora suprimidos no nível de regra e de arquivo.

Para suprimir a uma regra, clique com o botão direito do mouse um SCA aviso ou erro na lista de erro e escolha Suppress estático código Message (s análise). Regras que foram suprimidas são adicionadas ao arquivo chamado StaticCodeAnalysis.SupressMessages.xml na raiz do sistema do projeto. Para incluir regras que foram suprimidas, exclua o arquivo do projeto ou remover regra específica e combinações de arquivo do arquivo. a Figura 14 mostra a seção de análise de código da janela de propriedades do projeto com as novas opções.

A Figura 14 opções de análise de código estático

SCA pode ser habilitada como parte da compilação de um projeto de banco de dados. Se SCA estiver habilitada, ele será executado como parte de cada compilação de projeto e pode causar a compilação falhe se erros são detectados pelas SCA. Isso também é válido para compilações iniciadas a partir da linha de comando usando MSBuild. O GDR também fornece um destino de SCA MSBuild (StaticCodeAnalysis), que permite SCA a ser executada independentemente da opção Ativar SCA para compilação.

SCA pode ser configurada por projeto, que significa que um conjunto diferente de regras e opções de erro pode ser definido para cada configuração ou o ambiente. Executar SCA a partir da linha de comando produz um arquivo de resultados chamado StaticCodeAnalysis.Results.xml. Este arquivo é gravado para o diretório do qual o MSBuild é chamado. Os resultados nome do arquivo e local pode ser alterada, substituindo a propriedade ResultsFile.

Para executar SCA a partir da linha de comando usando MSBuild, use o seguinte comando:

msbuild MyDatabase.dbproj /t:StaticCodeAnalysis

A Figura 15 mostra um exemplo do SCA arquivo de resultados produzido.

A Figura 15 A exemplo SCA Results File

<?xml version="1.0" encoding="utf-8" ?> 
<Problems>
<Problems>
      <Rule>Microsoft.Design#SR0001</Rule> 
    <ProblemDescription>The shape of the result set produced by a SELECT 
    * statement will change if the underlying table or view structure 
    changes.</ProblemDescription> 
<SourceFile>C:\USERS\XXXX\DOCUMENTS\VISUAL STUDIO 2008\PROJECTS\ \
MYDATABASE\MYDATABASE\SCHEMA OBJECTS\SCHEMAS\DBO\PROGRAMMABILITY\STORED 
PROCEDURES\MYSTOREDPROC.PROC.SQL</SourceFile> 
  <Line>6</Line> 
  <Column>8</Column> 
  <Severity>Warning</Severity> 
  </Problems>
</Problems>

Tips e truques

Há uma série de outras alterações que acompanham o GDR que desejo Observação antes do artigo de quebra.

Com o GDR, agora você tem a capacidade de mover um objeto de um esquema para outro. Além disso, o GDR tem a capacidade de preservar alterações de refatoração e emitir o apropriado T-SQL para fazer essas alterações em relação ao servidor de destino durante a implantação. Por exemplo, se você renomear uma tabela, um sp_rename é emitida durante a próxima implantação em vez de descartar e recriar a tabela.

Os tipos de arquivos que podem ser referenciados por um projeto de banco de dados tiverem sido expandidos. Em GDR, uma referência é possível criar os seguintes tipos de arquivo:

Projetos
arquivos .dbschema
.dll (suporte a SQL CLR)
.xsd (XSD)

No caso de um projeto de banco de dados ou uma referência de arquivo .dbschema, o projeto está fazendo referência logicamente ao outro banco de dados. Se a referência não tiver nenhum nome de três ou quatro part, ele é considerado uma referência de projeto "Composição". Projetos compostos são um novo recurso que permite que um banco de dados ser logicamente dividido em vários projetos — a intenção foi dividir o esquema do banco de dados ao longo de segurança ou limites organizacionais — para o desenvolvimento e implantados manualmente na ordem correta. Projetos de composição só há suporte para referências de banco de dados-para-banco de dados, não banco de dados-para-servidor ou servidor a servidor referências. No caso de uma referência de banco de dados-para-servidor, a referência é propagada com o literal "mestre."

Como mencionado anteriormente no artigo, referências a projetos SQL CLR, .DLLs e .XSDs são referências que incluem o objeto referenciado para o banco de dados para que ele pode ser usado pelo restante da seu código-fonte. Esses objetos de referência serão implantados como parte da implantação de seu projeto de banco de dados.

Na versão GDR, a página de propriedades de implantação possui foi reformulada para permitir a delegação fácil se as configurações estão armazenadas no arquivo de projeto (.dbproj) ou o arquivo de configuração do usuário (.user). a Figura 16 mostra um exemplo.

A Figura 16 configurações de área de segurança

Com essa nova página de propriedade, você pode especificar o local em que as configurações são armazenadas. Por padrão, as seqüências de caracteres de conexão e o restante da configuração de implantação é armazenado no arquivo de projeto e compartilhado entre os membros da equipe. Se a lista suspensa configuração for alterada para meu ambiente de desenvolvimento isolado, as configurações em definições do banco de dados de destino serão armazenadas no arquivo .User.

Testes de unidade de banco de dados apenas ligeiramente foi modificada para liberar o GDR. Uma alteração foi adicionada ao melhor suporte a desenvolvimento controlado por testes, onde um projeto de banco de dados é implantado sempre que um teste é executado. Com o novo divididas entre o build e implantar, o desenvolvimento controlado por testes sofreu um impacto porque o projeto de banco de dados, na verdade, foi implantado sempre testes foram executados no desempenho. (Isso não era verdadeiro em versões anteriores, no qual o script de implantação seria curto-circuito se ele já tinha sido executado.)

Como a maioria dos desenvolvedores irá usar um banco de dados seguro para sua execução de teste unidade e atualizar somente que seguro por meio de execuções de teste, uma configuração foi adicionada que executará implantação do projeto de banco de dados somente se o .dbschema para o projeto for mais recente do que o script. SQL. Para habilitar essa configuração, modifique app.config o projeto de teste conforme mostrado aqui:

<DatabaseDeployment 
 DatabaseProjectFileName="..\..\..\Database1\Database1.dbproj"
 Configuration="Debug" ForceDeployment="false"/>

Para detectar se implantação precisa para ser executado e para distinguir de implantação para outras máquinas, o script de implantação recebe o nome do banco de dados seguro. Por exemplo, meu banco de dados seguro é denominado Database1Sandbox, portanto, o script de implantação é denominado UnitTestDeployment_Database1Sandbox.sql. Como mencionado antes, esta configuração não deve ser usada se o esquema do banco de dados seguro for modificado de forma alguma diferente por meio da execução do teste de unidade.

Extensibilidade também foi atualizada no GDR para tornar a forma de extensões que irá direcionar provedores de banco de dados diferente. Para definir uma classe como uma extensão direcionamento de um provedor específico, você precisará decorá-lo com o DatabaseSchemaProviderCompatibilityAttribute. Para um gerador de dados que se destina todas as versões do SQL, isso poderia parecer com o seguinte:

[DatabaseSchemaProviderCompatibility(typeof(SqlDatabaseSchemaProvider))]

Testes de unidade não inclui o conceito de um provedor de banco de dados de destino ainda, e todas as condições de teste existentes são independente do provedor. Para definir um novo teste condição adicione os seguintes atributos:

[DatabaseSchemaProviderCompatibility(DspCompatibilityCategory.Any)]
[DatabaseSchemaProviderCompatibility(DspCompatibilityCategory.None)]

Esses atributos indicam que esta condição de teste é válida se nenhum provedor de esquema do banco de dados estiver presente e a condição de teste também é válida para todos os provedores de esquema do banco de dados.

ele Laflen é técnico líder da equipe DBPro. Ele é responsável pela unidade de teste, geração de dados e recursos de criação/implantar. Antes de ingressar a equipe de desenvolvimento, Jaime fazia parte do Microsoft Services e ajudou a clientes implemement os aplicativos .NET dentro do Visual Studio.

Barclay Hill é gerente de programa e um novo membro da equipe DBPro. Barclay vem à equipe depois levando os esforços de desenvolvimento empresarial banco de dados do aplicativo em várias indústrias por muitos anos.

Recursos adicionais