Najpierw debuguj kody migracji Entity Framework

Najpierw używam kodu Entity Framework w mojej witrynie i po prostu zastanawiam się, czy istnieje sposób na debugowanie kodów migracji. Wiesz, na przykład ustawianie punktów przerwania i tym podobne.

Używam konsoli Menedżera pakietów do aktualizacji bazy danych przy użyciu Update-Database.

Dzięki

Wiem, że EF Code First Migrations jest stosunkowo nowym narzędziem, ale nie zapominaj, że nadal korzystasz z platformy .NET.

Możesz więc użyć:

if (System.Diagnostics.Debugger.IsAttached == false)
{
    System.Diagnostics.Debugger.Launch();
}

Następnie możesz zobaczyć swój wyjątek InnerException.

Lub możesz użyć instrukcji try ... catch w następujący sposób: obsługa wyjątków Entity Framework

Aby osiągnąć punkt przerwania w migracji bazy danych, ustaw kontekst na MigrateDatabaseToLatestVersion podczas inicjalizacji.

Database.SetInitializer(new MigrateDatabaseToLatestVersion<EnterContextHere, Configuration>());

Następnie po prostu debugujesz w normalny sposób (uruchamiasz przy użyciu f5), a punkt przerwania zostanie osiągnięty przy pierwszym uruchomieniu projektu.

Problem polega na tym, że jeśli debugujesz po raz drugi, migracja nie zostanie uruchomiona. Dzieje się tak, ponieważ tabela __MigrationHistory została zaktualizowana i zawiera informację o migracji do najnowszej wersji. Aby ponownie przetestować migrację, otwórz konsolę menedżera pakietów i powróć do poprzedniej migracji:

Update-Database –TargetMigration: ThePreviousMigrationName

Moja odpowiedź może być trochę głupia, ale tak czy inaczej. Jeśli ty, tak jak ja, czasami masz problemy z metodą Seed (), zwykle po prostu tworzę publiczną metodę, która wywołuje Protect Seed ().

public void SeedDebug(AppDbContext context)
{
    Seed(context);
}

następnie w moim HomeController wywołuję tę metodę w trybie debugowania.

public class HomeController : Controller
{
    var appDb = new AppDbContext();
    public ActionResult Index()
    {
        var config = new Configuration();
        config.SeedDebug(appDb);
        return View();
    }
}

Wiem, że to trochę kiepskie rozwiązanie, ale jest proste i szybkie. Oczywiście należy to zrobić po utworzeniu modelu. Więc krok po kroku:

1. skomentuj metodę początkową i wykonaj aktualizację bazy danych, aby utworzyć model

2. odkomentuj metodę Seed () i podłącz "hack", o którym wspomniałem powyżej.

3. w konfiguracji wyłącz automatyczne migracje

   AutomaticMigrationsEnabled = false; // jeśli ta opcja jest wyłączona, pomiń ten krok

4. Debuguj aplikację, napraw błąd i usuń „hack”

Oto bardziej niezawodna metoda, która wystarczy bez większego zamieszania:

Krok 1: Umieść ten fragment kodu tuż nad migracją, którą chcesz debugować:

public partial class ORACLE_Test : DbMigration
{
    public override void Up()
    {
        if (!System.Diagnostics.Debugger.IsAttached)
            System.Diagnostics.Debugger.Launch();

        AddColumn("TEST", "UR_USER_ID", x => x.Decimal(nullable: false, precision: 11, scale: 0, storeType: "number"));
        AddColumn("TEST", "UR_CLIENT_ID", x => x.Decimal(nullable: false, precision: 11, scale: 0, storeType: "number"));
        [...]
    }

    public override void Down()
    {
    }
}

Krok 2: Skompiluj projekt zawierający Twoje migracje

Krok # 3: Otwórz konsolę w katalogu wyjściowym (/ bin / Debug, / bin / Release itp.) Zawierającym bibliotekę dll Twoich migracji

Krok 4: Wywołaj migrate.exe z parametrem / scriptFile, aby uruchomić debuger i faktycznie debugować żądaną migrację db

migrate.exe "Your.Migrations.Assembly.dll" /scriptFile="foo.sql" /verbose /startupConfigurationFile="Your.Migrations.Assembly.config"

Gdy pojawi się okno dialogowe wyboru debugera, wybierz już otwartą instancję programu Visual Studio.

Możesz dodać instrukcje Console.WriteLine do kodu migracji (nie jest to świetne rozwiązanie)

Uwaga, komunikaty są wyświetlane tylko wtedy, gdy uruchomisz kod migracji za pomocą migrate.exenarzędzia (in pacakges\EntityFramework.x.y.z\tools). Nie będą wyświetlane, jeśli migracja zostanie uruchomiona za pośrednictwem konsoli Menedżera pakietów.

Miałem dużo szczęścia przy używaniu "Debugger.Launch ()" (jak w powyższej odpowiedzi m_davida ) w innym miejscu, ale w CreateDbContext wydaje się, że w jakiś sposób zarówno dołącza, jak i nie dołącza. Chodzi mi o to, że dołącza i zaczyna próbować wejść do plików .asm i .cpp (kod wewnętrzny). Jeśli spróbuję ustawić punkt przerwania na Console.Writeline, który WIEM, że zostanie wykonany później (widzę dane wyjściowe z DOWOLNEGO POLECENIA „dotnet ef migrations”), wykonuje go i nigdy nie trafia do punktu przerwania.

Zamiast tego zadziałało dla mnie:

while (!System.Diagnostics.Debugger.IsAttached)
    System.Threading.Thread.Sleep(10);

// Breakpoint after this...

Można wykonać migrację i ręcznie zamocować za pomocą Visual Studio i to będzie rzeczywiście pozwalają prześledzić kod jak można się spodziewać, to tylko więcej bólu. To, co naprawdę powinienem spróbować, to połączenie obu metod ...

Znalazłem również schludny sztuczki tutaj aby uzyskać szczegółowe informacje o błędzie ...

Zasadniczo sztuczka polega na przejęciu wszystkich informacji z wyjątku, umieszczeniu ich w ciągu i rzuceniu nowego wyjątku DbEntityValidationException z wygenerowanym ciągiem i oryginalnym wyjątkiem.