Si bien esta pregunta se basa en no preocuparse por los datos, a veces el mantenimiento de los datos es esencial.
Si es así, escribí una lista de pasos sobre cómo recuperarse de la pesadilla de Entity Framework cuando la base de datos ya tiene tablas con el mismo nombre aquí: Cómo recuperarse de la pesadilla de Entity Framework: la base de datos ya tiene tablas con el mismo nombre
Aparentemente ... un moderador consideró adecuado eliminar mi publicación, así que la pegaré aquí:
Cómo recuperarse de la pesadilla de Entity Framework: la base de datos ya tiene tablas con el mismo nombre
Descripción : si eres como nosotros cuando tu equipo es nuevo en EF, terminarás en un estado en el que no podrás crear una nueva base de datos local o no podrás aplicar actualizaciones a tu base de datos de producción. Desea volver a un entorno EF limpio y luego seguir con lo básico, pero no puede. Si lo hace funcionar para producción, no puede crear una base de datos local, y si lo hace funcionar para local, su servidor de producción se desincroniza. Y finalmente, no desea eliminar ningún dato del servidor de producción.
Síntoma : no se puede ejecutar Update-Database porque está intentando ejecutar el script de creación y la base de datos ya tiene tablas con el mismo nombre.
Mensaje de error: System.Data.SqlClient.SqlException (0x80131904): ya existe un objeto llamado '' en la base de datos.
Antecedentes del problema : EF comprende dónde se encuentra la base de datos actual en comparación con dónde se encuentra el código según una tabla en la base de datos llamada dbo .__ MigrationHistory. Cuando mira las secuencias de comandos de migración, intenta reconciliar dónde estaba por última vez con las secuencias de comandos. Si no puede, solo intenta aplicarlos en orden. Esto significa que vuelve a la secuencia de comandos de creación inicial y si observa la primera parte del comando ARRIBA, será la tabla CreeateTable para la tabla en la que se produjo el error.
Para entender esto con más detalle, recomiendo ver los dos videos mencionados aquí:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Solución : Lo que debemos hacer es engañar a EF para que piense que la base de datos actual está actualizada sin aplicar estos comandos de CreateTable. Al mismo tiempo, todavía queremos que esos comandos existan para poder crear nuevas bases de datos locales.
Paso 1: Producción de base de datos limpia
Primero, haga una copia de seguridad de su producción db. En SSMS, haga clic con el botón derecho en la base de datos, seleccione "Tareas> Exportar aplicación de nivel de datos ..." y siga las instrucciones. Abra su base de datos de producción y elimine / suelte la tabla dbo .__ MigrationHistory.
Paso 2: limpieza del entorno local
Abra su carpeta de migraciones y elimínela. Supongo que puede recuperar todo esto de git si es necesario.
Paso 3: Recreate Initial
En el Administrador de paquetes, ejecuta "Enable-Migrations" (EF te pedirá que uses -ContextTypeName si tienes varios contextos). Ejecute "Add-Migration Initial -verbose". Esto creará el script inicial para crear la base de datos desde cero en función del código actual. Si tuvo alguna operación de inicialización en Configuration.cs anterior, cópielo.
Paso 4: Truco EF
En este punto, si ejecutamos Update-Database , obtendríamos el error original. Por lo tanto, debemos engañar a EF para que piense que está actualizado, sin ejecutar estos comandos. Entonces, vaya al método Up en la migración inicial que acaba de crear y coméntelo todo.
Paso 5: Actualización de la base de datos
Sin código para ejecutar en el proceso Up, EF creará la tabla dbo .__ MigrationHistory con la entrada correcta para decir que ejecutó este script correctamente. Ve y échale un vistazo si quieres. Ahora, descomenta ese código y guarda. Puede ejecutar Update-Database nuevamente si desea verificar que EF cree que está actualizado. No ejecutará el paso Arriba con todos los comandos CreateTable porque cree que ya lo ha hecho.
Paso 6: Confirme que EF esté ACTUALMENTE actualizado
Si tenía un código que aún no tenía migraciones aplicadas, esto es lo que hice ...
Ejecute "Add-Migration MissingMigrations" Esto creará prácticamente un script vacío. Debido a que el código ya estaba allí, en realidad había los comandos correctos para crear estas tablas en la secuencia de comandos de migración inicial, por lo que simplemente corté los comandos CreateTable y equivalentes en los métodos Arriba y Abajo.
Ahora, ejecute Update-Database nuevamente y observe cómo ejecuta su nuevo script de migración, creando las tablas apropiadas en la base de datos.
Paso 7: Vuelva a confirmar y confirme.
Construye, prueba, corre. Asegúrese de que todo se esté ejecutando y luego confirme los cambios.
Paso 8: Informe al resto de su equipo cómo proceder.
Cuando la próxima persona se actualice, EF no sabrá qué impacto dado que los scripts que había ejecutado antes no existen. Pero, suponiendo que las bases de datos locales se puedan volar y recrear, todo esto es bueno. Tendrán que soltar su base de datos local y agregar crearla desde EF nuevamente. Si tenían cambios locales y migraciones pendientes, recomendaría que vuelvan a crear su base de datos en el maestro, cambien a su rama de características y vuelvan a crear esos scripts de migración desde cero.
DROP DATABASE
entonces ...