Есть ли способ заставить LinqPad работать с контекстом EF Core?

Question

Я пытаюсь выяснить, есть ли что-то, чего я не вижу или каким-то образом взломать отсутствие поддержки (пока) для Entity Framework Core DbContexts в LinqPad. Я скомпилировал свой целевой код 4.6.1 (как suggested on the LinqPad forum) и попробовал драйвер «Entity Framework V7», но, как видно из его названия, я не верю, что он обновлен. Он по-прежнему запрашивает файл app.config или строку подключения для конструктора.

Поскольку Основные контексты EF использовать DbContextOptions для строительства, а не строки соединения, я думал, что я мог бы создать перегрузку конструктора, который принимает строку подключения, но не обрабатывает драйвер базы данных. Есть ли способ указать фабрику для конструирования контекста? Любые другие возможности? Я чувствую себя потерянным без LinqPad.

Answer 1

Похоже, что драйвер неисправен/не обновляется. Я нашел способ обойти его, изменив DbContext.

В теории, это должно было сработать, но это не делает:

private string _connectionString; 
public ApplicationDbContext(string connectionString) : base() 
{ 
    _connectionString = connectionString; 
} 
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) 
{ 
    if (_connectionString == null) 
     base.OnConfiguring(optionsBuilder); // Normal operation 

    // We have a connection string 
    var dbContextOptionsBuilder = new DbContextOptionsBuilder(); 
    optionsBuilder.UseSqlServer(_connectionString); 
    base.OnConfiguring(dbContextOptionsBuilder); 
} 

драйвер LINQPad EF Ядро продолжает искать конструктор без параметров, даже если вы укажете «Через конструктор, который принимает строку». Это похоже на ошибку в драйвере.

Итак, я дал ему то, что он хотел, без параметров. Мне пришлось жестко кодировать строку подключения, поскольку IoC/appsettings.json config reader не загружен, и я не чувствую, что загружаю его отдельно в DbContext. Но он работает и позволяет мне тестировать запросы EF Core в LinqPad с моей модели.

Это прекрасно работает для меня:

private bool _isDebug = false; 
public ApplicationDbContext() : base() 
{ 
    _isDebug = true; 
} 
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) 
{ 
    if (!_isDebug) 
     base.OnConfiguring(optionsBuilder); // Normal operation 

    // We are in debug mode 
    var dbContextOptionsBuilder = new DbContextOptionsBuilder(); 
    // Hardcoded connection string 
    optionsBuilder.UseSqlServer("data source=XXXX;initial catalog=XXXX;persist security info=True;user id=XXXX;password=XXXX;MultipleActiveResultSets=True;App=EntityFramework"); 
    base.OnConfiguring(dbContextOptionsBuilder); 
} 

Это в дополнение к существующему public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } конечно.

Редактировать: Будьте осторожны, похоже, что это переопределяет поведение по умолчанию, которое может не отображаться до тех пор, пока вы не развернетесь на сервере.

Answer 2

Последний EFCore 1.1 Драйвер LINQPad (v1.1.1.1) может корректно использовать конструктор, который принимает строку (если эта опция выбрана в LINQPad).

Так что можно добавить следующий конструктор:

public ApplicationDbContext(string connectionString) : this(new DbContextOptionsBuilder<ApplicationDbContext>() 
     .UseSqlServer(connectionString).Options) 
    { } 

Это будет трудно связать этот экземпляр контекста для SQL сервера провайдера, но по крайней мере не в строку подключения. И, кроме того, ваше приложение вряд ли когда-либо попытается использовать этот конструктор, EF Core никогда не ожидает/не продвигает ctor. который принимает строку.

Для дополнительной безопасности вы можете обернуть этот конструктор в #if DEBUG ... #endif, чтобы он никогда не попадал в производство.