我們在一個項目中使用EF遷移工作有3種狀態：EF遷移問題
我們在開發中沒有問題：我們已經改變了我們的DbContext和EF遷移改變了我們的數據庫。每個開發人員都有正確的代碼和正確的數據庫。
當我們上傳項目到分期時，問題出現了。我們需要更新升級數據庫，因爲
因爲數據庫創建
模型來頭「XXX」環境已經改變，但如果我們更新數據庫（使用遷移），生產投相同的消息（因爲Production和Staging具有相同的數據庫）。
數據庫的更改很少，所以如果我們不使用EF遷移就沒有問題。
有什麼建議嗎？
也許是您在Staggig和Production中使用相同數據庫的設計問題。
但
數據庫的變化是微乎其微的
已經是不相同的數據庫。當然你不能計算相同的散列值，即使在小變化=）
我認爲這是它應該工作的方式。
我們還爲每個開發者本地測試數據庫提供了一些開發數據庫 - 用於測試目的和生產力數據庫。
而所有這三者都是不同的實例。
我知道這已經被回答了 - 但只是爲了增加對「歷史的目的」和其他人可能會看到這...
，你所擁有的情景 - 同時支持Production和Staging支持與同數據庫 - 從Migrations的角度來看有點問題。
您可以取消遷移 - 刪除遷移表（__MigrationHistory）並同步事物（請參閱下面的帖子以獲取更多信息） - 但有兩個代碼庫指向相同的Db表示one migration table - 除非代碼是相同（遷移方式），它將無法工作。所以唯一的解決方案是關閉遷移。
但是，隧道盡頭似乎有一道光線。
來自EF（EF6預發行版）的新版本有Code First Migrations History Table Customization。
我沒有設法時間尚未與該打，但是...
它的意思是 - 簡單地說，你可以定製你的Configuration並覆蓋IHistoryContextFactory。 這又可以讓您重命名遷移表。
對於更復雜的場景 - 像你 - 這可能是一個解決方案
注意，它沒有得到證實 - 但我想，他們把它放在那裏 對於那些非常的原因。
A「僞解決方案」是這樣的......
可以工作，我想。 ..
How to Synchronize Db/Code - Summary
How to Synchronize Db/Code - Long Version
似乎有趣的極端！謝謝 ;） – Subgurim
是我期待的答案：d #thanks – Subgurim
很樂意幫助你=） – MikroDel