Есть контекст в проекте.
На него настроены миграции.

Всё нормально.

Добавляю в решение консольный проект - пустяк. Там НИЧЕГО нет. Только то, что ставит студия по умолчанию.

После этого миграции не работают.

Сперва просят поставить в пустой консольный фреймворк EF.
Потом просят "сконфигурировать" миграции для пустого проекта - что за чушь??

Что с этим можно сделать??

hVosttMonochromatiqueЧто с этим можно сделать??

С чем? Да, надо референсить EF, и EF должен быть сконфигурирован в config-файле именно приложения, а не подключенной библиотеки, если не используется полностью программное конфигурирование, а контекст EF-а не торчит наружу. Так что всё нормально. Не вижу проблемы.

Я нифига не понял. Мне надо подключить EF к консольному проекту? Ну даже допустим.

Как мне сконфигурировать миграции для консольного проекта, имеющего один пустой метод main??

hVosttMonochromatiqueКак мне сконфигурировать миграции для консольного проекта, имеющего один пустой метод main??

А где они у тебя раньше были сконфигурированы?

В единственном проекте, MVC-приложения, где и находился наследник DbContext-а

hVosttMonochromatiqueВ единственном проекте, MVC-приложения, где и находился наследник DbContext-а

Ничё не понял. У тебя был 1 веб-проект, так? Потом ты добавляешь в солюшен +1 консольный проект, который никак не связан с веб-проектом и у тебя отваливаются миграции?

Да, именно. Только в консольном проекте я сослался на web-проект - так что связаны.

hVosttMonochromatiqueДа, именно. Только в консольном проекте я сослался на web-проект - так что связаны.

Чёто вафля какая-то. Вынеси слой с EF в class library и ссылайся на него. Защем на веб-проект ссылаться-то?

Мне от EF вообще ничего не надо.
Консольное приложение - это AZURE WebJob. Оно должно запустить метод определенного класса, который как раз находится в WEB-проекте.

hVosttAxeleronНа Web проект нельзя ссылаться - это конечный UI по сути. От него не должен зависеть ни один другой проект, а вот UI может. Так что что-то у Вас с архитектурой совсем плохо. И конфигурационный файл для EF должен находиться в конечном проекте, которй вызывает контекст.

Об этом и талдычу ему. Я думал што у него этот метод в отдельной сборке, а он какую-то котовасию устроил.

Не знаю, что ты думал, но кроме мемеканья в этом треде от тебя ничего не было (тебя к такому стилю приучили?)

Axeleron И конфигурационный файл для EF должен находиться в конечном проекте, которй вызывает контекст.

Да он там и находится.

Вы хотите сказать, что вообще ВСЕГДА работу с БД (да и с чем угодно) - надо выносить в другие проекты? Мало ли придется в эту же БД писать НЕ ИЗ Web-проекта?

AxeleronMonochromatiqueДа он там и находится.

Вы хотите сказать, что вообще ВСЕГДА работу с БД (да и с чем угодно) - надо выносить в другие проекты? Мало ли придется в эту же БД писать НЕ ИЗ Web-проекта?

Да, обычно для Data Access Layer создают отдельный проект (если не солюшн даже). В том-то и дело, что 'Мало ли придется в эту же БД писать НЕ ИЗ Web-проекта'. Тогда Вам просто достаточно будет добавить референс к сборке DAL и вуаля!

Из-за одного азуровского джоба разделять всё по разным проектам?

Сейчас поставил эксперимент. Добавил консольное приложение, сослался WEB-проект из него - и поигрался с миграциями.

Всё однако прокатило. O_O

Получается, что мастер азуровского джоба где-то фонит?? O_o

MonochromatiqueВсё однако прокатило. O_O

Нюанс - там где прокатило - стоит VS 2013 со вторым апдейтом.

Там где нет - последняя..

И чо та сдается мне, что при любом раскладе - я опять упрусь в эту же проблему.

AxeleronMonochromatiqueПолучается, что мастер азуровского джоба где-то фонит?? O_o

Чует мое сердце, что фоните где-то все-таки Вы

Там ошибиться негде. Но тем не менее - всё создал заново - и всё прошло как по маслу.

Даже странно.