Embora essa questão tenha como premissa não se importar com os dados, às vezes a manutenção dos dados é essencial.
Em caso afirmativo, escrevi uma lista de etapas sobre como recuperar o pesadelo do Entity Framework quando o banco de dados já possui tabelas com o mesmo nome aqui: Como recuperar o pesadelo do Entity Framework - o banco de dados já possui tabelas com o mesmo nome
Aparentemente ... um moderador achou adequado excluir minha postagem, então colarei aqui:
Como recuperar do pesadelo do Entity Framework - o banco de dados já possui tabelas com o mesmo nome
Descrição : se você gosta de nós quando sua equipe é nova na EF, você terminará em um estado em que não poderá criar um novo banco de dados local ou não poderá aplicar atualizações ao banco de dados de produção. Você quer voltar para um ambiente EF limpo e seguir o básico, mas não pode. Se você trabalhar para produção, não poderá criar um banco de dados local e, se trabalhar para local, seu servidor de produção ficará fora de sincronia. E, finalmente, você não deseja excluir nenhum dado do servidor de produção.
Sintoma : Não é possível executar o Update-Database porque está tentando executar o script de criação e o banco de dados já possui tabelas com o mesmo nome.
Mensagem de erro: System.Data.SqlClient.SqlException (0x80131904): Já existe um objeto chamado '' no banco de dados.
Histórico do problema : O EF entende onde o banco de dados atual está comparado com o código, com base em uma tabela no banco de dados chamada dbo .__ MigrationHistory. Quando olha para os scripts de migração, ele tenta reconsilar onde estava com os scripts. Se não puder, apenas tenta aplicá-las em ordem. Isso significa que ele volta ao script de criação inicial e, se você observar a primeira parte do comando UP, será a CreeateTable da tabela em que o erro estava ocorrendo.
Para entender isso com mais detalhes, recomendo assistir aos dois vídeos mencionados aqui:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Solução : O que precisamos fazer é induzir a EF a pensar que o banco de dados atual está atualizado enquanto não aplica esses comandos CreateTable. Ao mesmo tempo, ainda queremos que esses comandos existam para que possamos criar novos bancos de dados locais.
Etapa 1: DB de produção limpo
Primeiro, faça um backup do seu banco de dados de produção. No SSMS, clique com o botão direito do mouse no banco de dados, selecione "Tarefas> Exportar aplicativo da camada de dados ..." e siga as instruções. Abra seu banco de dados de produção e exclua / solte a tabela dbo .__ MigrationHistory.
Etapa 2: Limpeza do ambiente local
Abra sua pasta de migrações e exclua-a. Estou assumindo que você pode recuperar tudo isso do git, se necessário.
Etapa 3: Recriar a inicial
No Package Manager, execute "Enable-Migrations" (a EF solicitará que você use -ContextTypeName se você tiver vários contextos). Execute "Add-Migration Initial -verbose". Isso criará o script inicial para criar o banco de dados do zero com base no código atual. Se você teve alguma operação inicial no Configuration.cs anterior, copie-a.
Etapa 4: Truque EF
Neste ponto, se executássemos o Update-Database , estaríamos recebendo o erro original. Portanto, precisamos induzir a EF a pensar que está atualizada, sem executar esses comandos. Portanto, entre no método Up na migração inicial que você acabou de criar e comente tudo.
Etapa 5: Atualizar banco de dados
Sem código a ser executado no processo Up, o EF criará a tabela dbo .__ MigrationHistory com a entrada correta para dizer que executou esse script corretamente. Vá e confira se quiser. Agora, remova o comentário desse código e salve. Você pode executar o Update-Database novamente se quiser verificar se o EF está atualizado. Ele não executará a etapa Up com todos os comandos CreateTable, porque acha que já fez isso.
Etapa 6: confirmar se a EF está realmente atualizada
Se você tinha um código que ainda não tinha migrações aplicadas a ele, foi isso que eu fiz ...
Executar "Migração Missing de Adicionar Migração" Isso criará praticamente um script vazio. Como o código já estava lá, havia realmente os comandos corretos para criar essas tabelas no script de migração inicial, então eu apenas cortei os comandos Drop e CreateTable e equivalentes nos métodos Para cima e Para baixo.
Agora, execute o Update-Database novamente e observe-o executar seu novo script de migração, criando as tabelas apropriadas no banco de dados.
Etapa 7: confirme novamente e confirme.
Construa, teste, execute. Verifique se tudo está em execução e confirme as alterações.
Etapa 8: informe ao restante da equipe como proceder.
Quando a próxima pessoa atualizar, a EF não saberá o que ocorreu, uma vez que os scripts executados antes não existem. Mas, supondo que os bancos de dados locais possam ser ampliados e recriados, tudo isso é bom. Eles precisarão descartar o banco de dados local e adicionar criá-lo da EF novamente. Se eles tiverem alterações locais e migrações pendentes, eu recomendo que eles criem seu banco de dados novamente no master, alternem para a ramificação de recursos e recriem esses scripts de migração do zero.
DROP DATABASE
então ....