Не удалось найти входные данные в файле конфигурации

Обновлено: 03.07.2024

(2) cool.vlad4,
Ребят, оч помощь нужна.
Обновлял базу , бэкап не сделал, так уж получилось, в процессе обновление , оборвался доступ к папке с базой и аля писец.
Ситуация как тут.

Я не знаком на столько тонко и весьма трудно, прошу разъяснить некоторые моменты.

Итак , пытаясь сделать как описано тут , не очень получилось, меня интересует след:
1. Что есть блок? Конкретно Блок 2. Корневой объект. Не могу въехать, как его определить?
2. как определить начало конфигурации и ее конец, что заменять?
3. Если как тут описано заменять от CONFIG до CONFIGSAVE , то , кусок из чистой , во много раз меньше, допустим
чистая - кусок - 9000 - 15000
битая - кусок- 9000-03630989
как-то так
Ну и как результат он мну шлет( Хочется разобраться самому , но трудно
Как-то получилось , заменит конфу, протестить, как итог база весила 80 мб, и ниодной конфы внутри( загружать конфу так же не давало , писало , что-то про исключительный доступ к 1сд.

спасибо, пока только порчу базу копированием, но буду дальше вставлять ) просто есть програмка cfexport, думал может есть cfimport) (3) Если проблема еще актуальна, можете выложить на файлообменник базу и конфигурацию и дать мне ссылку в личку. У меня есть опыт такого восстановления баз.

Выкладывайте ради спортивного интереса, терять вам все равно уже нечего.

Только базу до "лечения" chdbfl - знаем мы этого "хирурга".

То, что действительно важно, не держат в единственном экземпляре, да еще и на флешке. awa пишет:
(3) Если проблема еще актуальна, можете выложить на файлообменник базу и конфигурацию и дать мне ссылку в личку. У меня есть опыт такого восстановления баз.
У нас аналогичная проблема с базой. Предложение о восстановлении такаих БД в силе, Вы можете посмотреть БД? зачем выяснять размер таблицы если заменять надо от config до configsave cool.vlad4 пишет:
1. Открыть базу с помощью утилиты tool_1CD.exe (спасибо разработчику- http://infostart.ru/public/19633/) определяем размер таблицы CONFIG или CONFIGSAVE в базах. 2. С помощью текстовых редакторов находим это место в базе. можно с помощью TotalCommander разбить файл, чтобы таблица CONFIG могла попасть в одну из частей. Затем отредактировать, Полученные файлы. 3. Редактируем кусочек текста между <"Folder","Config", и <"Folder","ConfigSave", - это конфигурация, надо заменить на кусок из работующей конфигурации. 4. Собираем TotalCommander-ом, сохраняем, даже если будет жаловатся(на crc).

А можете посоветовать что-нибудь для моего случая? Желательно поподробнее с пояснениями действий. БД 1С:Бухгалтерия для Казахстана объемом около 10Гб, была криво перенесена из 7.7 в 8.1. А потом была повреждена из-за отключения света. Частично БД восстановил с помощью chdbfl, но база при ТиИ выдает следующую ошибку:


awa пишет:
Если проблема еще актуальна, можете выложить на файлообменник базу и конфигурацию и дать мне ссылку в личку. У меня есть опыт такого восстановления баз.

(7) Невозможно ничего посоветовать, не видя базу. Случаи поломки базы бывают настолько разными, что никакого определенного порядка действий не существует. Если есть возможность выложить базу, могу посмотреть.

Кстати, для всех. При проверке утилитой chdbfl.exe делайте бэкап базы ДО запуска chdbfl.exe. Очень часто chdbfl.exe делает только хуже! Например, при сбое одного(!) бита во внутреннем файле описания таблицы, chdbfl.exe может эту таблицу удалить из базы целиком! Почему-то, большинство людей доверяют утилите chdbfl.exe. Но chdbfl.exe достаточно тупая утилита. Она проверяет структуру базы с точки зрения корректности 1CD, но не с точки зрения корректности конфигурации.

agentesecreto; 1_C; CaSH_2004; IlyaSR; nuelectro; MikleVV; valafan; MaxDavid; Lara.Builova; Ish_2; + 10 – Ответить

awa пишет:
Невозможно ничего посоветовать, не видя базу. Случаи поломки базы бывают настолько разными, что никакого определенного порядка действий не существует. Если есть возможность выложить базу, могу посмотреть.

Кстати, для всех. При проверке утилитой chdbfl.exe делайте бэкап базы ДО запуска chdbfl.exe. Очень часто chdbfl.exe делает только хуже! Например, при сбое одного(!) бита во внутреннем файле описания таблицы, chdbfl.exe может эту таблицу удалить из базы целиком! Почему-то, большинство людей доверяют утилите chdbfl.exe. Но chdbfl.exe достаточно тупая утилита. Она проверяет структуру базы с точки зрения корректности 1CD, но не с точки зрения корректности конфигурации.

как воостановить базу удалилась таблица остался только индексный файл просматривал Tool_1CD добавление реквизита в этом документе в конфигурации тоже не помогло что делать выгрузка в идентич. конфигурацию тож не помогает вот при добавлении реквизита ошибка В процессе обновления информационной базы произошла критическая ошибка.
по причине:
Ошибка СУБД:
Ошибка SQL: Таблица не найдена '_Document133'
по причине:
Ошибка SQL: Таблица не найдена '_Document133'
конфигурация типовая бухгалтерия для казахстана документ Поступленияе НМА (нематериальные активы) их всего то на сегодняшний момент 3 проводки есть по ним в бух.регистре (13) Выложи базу на файлообменник, ссылку в личку мне напиши. есть старая рабочая база годичной давности когда обновление делал а сейчас не проходит Есть база 8.2,chdbfl.exe - пишет база полностью разрушена, невозможно восстановить,Tool_1CD - говорит длина файла базы некорректна длине блока (0x1000), все да!? база труп, просто полугодовой отчет на носу, бухгалтера в истерике. База не стартует ни в режиме 1с, ни в конфигураторе, выдает ошибку, что база повреждена, бухгалтер говорит, что раньше было такое, нажимала перезапустить и все работало.

(16)
ежедневных бэкапов нет, да?

>>говорит длина файла базы некорректна длине блока (0x1000)

может возможно отредактить значение длины блока, чтобы оно соответствовало длине файла? (ну это, возможно, нубовское предположение - я не ковырялся совсем в этом (( )

Просматривал файл 1cv8.1CD через шестнадцатиричный редактор, поиск юникодовой текстовой строки "DBSCHEMA" ничего не выдал. Пытался "впихнуть" таблицу DBSCHEMA из чистой конфигурации 2.0.22.1 релиза, и из единственного апрельского бэкапа - не помогает. С ошибкой "Длина файла в блоках и количество блоков в заголовке не равны" я научился справляться, нужно менять значение в блоке 0. В таблице CONFIG помимо строк root, version и versions имеются строки root.new, version.new и versions.new. Если я правильно понимаю, это значит, что ИБ до конца не обновилась и висит в промежуточном состоянии.

В общем ситуация такова. Помогите чем можете. Подтолкните в нужном направлении или посоветуйте программу или утилитку. Буду рад любой помощи.

Ivanov_EV пишет:
и из единственного апрельского бэкапа

балиииииин. ну сколько раз говорили миру. ((((

по файловой базе ничего не скажу, не работаю с ними - может попробовать в крупные франчи или в 1С обратиться?

(19)
а после чего косяк собственно? посмотрите, а таблица сама по себе осталась в sql?

Сделайте бэкапов существующей базы побольше. Самый простой путь в самой оптимистичной ситуации - это просто скопировать таблицу из старой базы в эту скулем. Если сама по себе структура конфы не нарушена, 1С подцепит таблицу и данные.

А вот если в метаданных этой ТЧ уже нет, то это не поможет - 1С просто не увидит таблицу. Тогда можно попробовать создать её и перекачать данные из старой базы. Но вот подцепятся ли они или шаманства надо продолжать - хз.

(20) Проблема в (18) успешно решена. Почему-то большинство людей пишет о своих проблемах, когда ищут помощи, а о том, что они решены, написать не считают нужным.
Прошу прощения, что не отписался. Я был настолько рад, что совсем забыл о правилах хорошего тона.
awa, огромнейшее спасибо Вам еще раз.
В итоге случай был очень тяжелый. Пришлось заменять таблицу CONFIG, генерировать новую таблицу DBSCHEMA, и потом переносить 11 таблиц из старого архива, благо, ни в одной из этих одиннадцати таблиц не оказалась критически важных данных.
Насколько я понял, это были объекты конфигурации, добавленные в новом релизе. 1С:Предприятие 8.1 (8.1.12.101)"Управление торговлей", редакция 10.3 (10.3.6.8)
Ошибка СУБД:
Ошибка SQL: Таблица не найдена '_Document175_VT3663'
по причине:
Ошибка SQL: Таблица не найдена '_Document175_VT3663'
В табло Document175.VT3663 Документ.ОтчетКомиссионераОПродажах.ДокументыРасчетовСКонтрагентом
Просматривал базу Tool_1CD этого документа нет, но есть старая база с этим документом.Как восстановить? romansun пишет:
а после чего косяк собственно? посмотрите, а таблица сама по себе осталась в sql? (21) Если есть возможность, выложи битую базу и старую базу с целой таблицей на файлообменник, а ссылку в личку мне напиши.
(20) Проблема в (18) успешно решена. Почему-то большинство людей пишет о своих проблемах, когда ищут помощи, а о том, что они решены, написать не считают нужным. (23) В итоге случай был очень тяжелый. Пришлось заменять таблицу CONFIG, генерировать новую таблицу DBSCHEMA, и потом переносить 11 таблиц из старого архива, благо, ни в одной из этих одиннадцати таблиц не оказалась критически важных данных. ТИИ говорит что файл базы данных испорчен.
chdbfl зависает сразу же. В dt не выгружается уже.
Это конец базе или еще можно что нибудь с ней сделать для восстановления?

Я использую EF и создан .EDMX из него, но тогда я хотел, чтобы он использовался только для автоматического создания файлов классов.

затем я использовал файлы классов для создания модели сущностей, а затем создал контекст БД, а затем репозиторий. Я вызываю WebApi (который находится в отдельном проекте, но в том же решении) для доступа к репозиторию для получения данных. Пока я запускаю WebApi, я получаю ошибку,

но в моем DAL у меня есть webConfig, и у него есть следующая запись, поэтому я не совсем уверен, что пошло не так,

вы говорите "в моем DAL, у меня есть webConfig". Я предполагаю, что строка подключения находится в файле конфигурации библиотеки ссылочных классов, но не в основном файле конфигурации, который у вас есть в вашем проекте ввода (проект веб-api, я думаю, глядя на теги).

Если это так, просто скопируйте строку подключения в файл конфигурации проекта записи.

в файле DBContext удалите

EF 4.3, EF 5 и EF 6 не нравится строка подключения называется name=xxxxx

вставьте следующий раздел в раздел конфигурации .конфигурационный файл того же проекта, где ваши .файл edmx находится под.

вы также можете создать другую строку подключения для другой среды в.конфигурационный файл основного проекта и передать любую строку подключения в качестве параметра конструктора DBContext.

Я обнаружил, что это сработало:

1) Проверьте, есть ли у вас несколько "App.конфигурационный файл. 2) Проверьте, имеет ли неправильное имя, чем строка подключения, которую он должен использовать. 3) сохраните проект и запустите программу

Он должен работать сейчас.

самое простое решение:

удалить текущий файл edmx и связанную строку подключения в приложении.конфиг и добавьте элемент Edmx с тем же именем, что и предыдущий.

это работает для меня.

скопировать и вставить в строку connectionString в ваш веб-проект веб-API.файл конфигурации решит проблему.

Это глупо, но у меня была эта ошибка, которая была исправлена на Rebuild All !!
С таким же успехом можно было включать и выключать его.

Это мой tsconfig.json файл:

Это ошибка или я что-то не так делаю? Я недавно обновил Visual Studio 2015 до обновления 3. Кто-нибудь сталкивался с этим раньше?

Добавьте пустой файл машинописного текста в папку сценариев машинописного текста (местоположение вашего файла tsconfig), чтобы удовлетворить требования компилятора машинописного текста.

Я вообще не использую TypeScript в этом проекте, так что иметь дело с этим довольно неприятно. Я исправил это, добавив tsconfig.json и пустой файл file.ts в корень проекта. Tsconfig.json содержит следующее:

Если у вас есть массив include (на что, вероятно, жалуется линтер TypeScript):

И вы используете VSCode, вы можете очень легко перезапустить сервер TS в своем редакторе, чтобы он попросил его повторно оценить файл.

CMD + SHIFT + P (на Mac) откроет командную строку, а затем найдет команду TypeScript: Restart TS server

enter image description here

Когда вы создаете файл tsconfig.json с помощью tsc --init , он комментирует каталог входных и выходных файлов. Так что это основная причина ошибки.

Чтобы обойти проблему, раскомментируйте эти две строки:

Изначально после комментирования это будет выглядеть так, как указано выше.

Но все мои сценарии .ts были внутри папки src. Итак, я указал / src.

Обратите внимание, что вам необходимо указать расположение ваших сценариев .ts в rootDir.

Я получаю эту ошибку: «В файле конфигурации 'tsconfig.json' входных данных не обнаружено. Указанные пути включения были '["**/*"]' , а пути исключения - '["**/*.spec.ts","app_/**/*.ts","**/*.d.ts","node_modules"]' .

У меня есть файл .tsconfig, который читает файлы ts из папки "./src".

Проблема здесь в том, что исходная папка не содержит файлов .ts, и я запускаю tslint. Я решил проблему, удалив задачу tslint из моего файла gulp. Поскольку у меня нет файлов .ts для компиляции и линтинга. Моя проблема решена этим.

При использовании кода Visual Studio сборка проекта (т. Е. Нажатие Ctrl + Shift + B ) перемещает ваш .ts в папку .vscode (я не знаю, почему он это делает), а затем генерирует ошибку TS18003 . Я переместил свой файл .ts из папки .vscode обратно в корневую папку и заново построил проект.

Проект построен успешно!

Кстати, была такая же проблема.

Если у вас был мой случай, то, вероятно, у вас tsconfig.json находится не в том же каталоге, что и файл .ts.

(В моем случае я тупо имел рядом с launch.json и tasks.json внутри папки .vscode: P)

Если вам не нужна компиляция TypeScript, отключите ее в своем файле .csproj согласно этой публикации.

Просто добавьте следующую строку в свой файл .csproj :

У меня есть файл tsconfig.json , который не применяется ни к каким файлам .ts. Это в отдельной папке. Вместо этого я использую его только как основу для других файлов tsconfig через "extends": "../Configs/tsconfig.json" . Как только я переименовал базовый файл конфигурации во что-то другое, например base-tsconfig.json (и обновил операторы extends ) ошибка исчезла, а расширение все еще работало.

Я получил ту же ошибку, когда сделал резервную копию папки node_modules в том же каталоге. Когда это произошло, я пытался решить другую ошибку сборки. Надеюсь, этот сценарий кому-то поможет. Удалите папку резервного копирования, и сборка будет завершена.

Я получил ту же ошибку, и в моем случае это было потому, что vscode не мог распознать файл .ts .

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

Моя проблема в том, что когда я пытаюсь использовать DbContext ' MyEntites ', я получаю следующую ошибку:

Не удалось найти строку подключения с именем «MyEntities» в файле конфигурации приложения.

Я предполагаю, что проблема как-то связана с тем, что строка подключения находится в app.config библиотеки классов, а не в проекте MVC.

У кого-нибудь есть предложения?

Попробуйте скопировать строку соединений в файл .config в проекте MVC.

Работает отлично, но хотелось бы знать, почему указанный проект не использует свой собственный файл конфигурации для извлечения строки подключения. @ Александр Старый вопрос, но да, я также хотел бы знать, почему. @ Александр, платформа загружает и использует файл (ы) конфигурации для выполняющейся сборки. В данном случае это веб-проект. Библиотеки классов обычно не имеют своих собственных файлов конфигурации. Команды Enable-Migration при запуске в контексте NuGet COnsole смотрят файл конфигурации Startup Projects, а не обязательно тот проект, в котором вы, как вы думаете, будут. Просто установите проект с app.config, который вы хотите использовать для запуска проект. При желании сохраните строки подключения в одном файле конфигурации, а затем назовите их в других проектах с помощью <connectionString configSource = "../ ProjectDir / SharedConnections.config" />

Вы правы, это происходит потому, что библиотека классов (где файл .edmx) не является вашим стартапом / основным проектом.

Вам необходимо скопировать строку подключения в основной файл конфигурации проекта.

Если ваш стартовый / основной проект не имеет файла конфигурации (как это было в моем случае с консольным приложением), просто добавьте его (проект запуска - Добавить новый элемент -> Файл конфигурации приложения).

Более релевантную информацию можно найти здесь: MetadataException: невозможно загрузить указанный ресурс метаданных

Ключевой ответ на этот вопрос заключается в том, что библиотека классов (где находится файл .edmx) не является вашим проектом STARTUP. Я понял, что мой стартовый проект не был настроен на проект, в котором был мой web.config. Это было консольное приложение с другим app.config. Поэтому, если вы добавляете консольные приложения в свое веб-решение, убедитесь, что ваш веб-проект является стартовым проектом при запуске update-database! По какой-то причине я выгрузил свой основной проект, и после его перезагрузки я получил эту ошибку, пытаясь добавить миграции. Создание основного проекта запуска проекта снова решило проблему. Спасибо @Oren Мой стартовый проект был изменен по ошибке. Это ключевой бит. Ваш ответ действительно помог!

убедитесь, что вы делаете свой проект (с DbContext) в качестве запуска

на проекте правой кнопкой мыши и выберите

Добавьте в проект, который задан в качестве запуска, строку подключения в app.config (или web.config)

Вызови команду вот так

Update-Database -Script -ProjectName '<project name>' -StartupProjectName '<project name>' -ConnectionString 'data source=.;initial catalog=<db name>;integrated security=True;MultipleActiveResultSets=True' -ConnectionProviderName 'System.Data.SqlClient'

Тогда попробуйте еще раз

Это на самом деле проект содержит строку подключения, которая должна быть установлена ​​как стартовый проект, и обычно это не тот проект, в котором находится ваш файл DbContext . таким образом, в дополнение к тому, чтобы убедиться, что Package Mgr нацелен на нужный слой, должен быть тот же самый слой Set as Startup Project - согласно скриншоту, показанному выше. (даже если вы нажмете F5, вы не сможете запустить библиотеку классов) Это спасло мою жизнь. Несмотря на то, что в Диспетчере пакетов мне был задан проект по умолчанию для проекта, в котором был задан контекст, он все равно не переопределился. «Но это сработало вчера! Точно такая же команда !» => ЭТО!

Вы можете просто передать строку подключения EntityFramework и продолжить свою жизнь:

и сделал мой день также, потому что я не мог найти решение, почему мой проект запуска внезапно прекратил находить файл конфигурации. Мои app.config и <appname> .exe.config обнаруживались в моей корзине автозагрузки проекта, но EntityFramework не смог найти строку подключения, которую я использовал вечно. Недавно я удалил несколько неиспользуемых проектов из решения, и мне интересно, было ли это как-то связано с этим. Я удалил веб-проект из решения. Хотите знать, полагались ли мои другие проекты на web.config или что-то необычное в этом роде? Конфигурация запущенного проекта используется всеми другими дочерними проектами.

Как вы предполагаете, это связано с тем, что строка подключения находится в app.config библиотеки классов.

Скопируйте запись из класса app.config в контейнер app.config или web.config файл

Если у вас есть несколько проектов в решении, настройте проект как запущенный там, где у вас есть ваш App.config.

скопировать строку подключения app.config или web.config файл в проекте, для которого установлено «Установить как StartUp проект», и, если в случае использования инфраструктуры сущностей в проекте уровня данных - установите Nuget инфраструктуры сущностей в основном проекте.

Это также происходит , если проект стартапа изменен на тот, который не имеет в строках подключения .

  1. Решение правой кнопкой мыши - щелкните свойства
  2. Под Общими свойствами выберите запуск проекта
  3. На правой панели выберите проект, который имеет строки подключения (в большинстве случаев это будут проекты MVC - проект, который запускает решение)
Да, это работает. Я создал библиотеку классов для EF для связи с БД, и у меня возникла та же проблема.
  1. Добавить файл App.Config
  2. Установите проект в качестве запуска проекта.

Убедитесь, что вы добавили строки подключения после entityFramework раздела:

Вы используете более одного проекта в своем решении?

Потому что, если вы, веб-конфигурация, которую вы должны проверить, находится в том же проекте, что и файл de .edmx.

Да, это так. Проект, содержащий строку подключения, является библиотекой классов, которая включает только файл App.config. Проект MVC, кажется, не проверяет это. во время разработки он будет проверять только app.config своего проекта, вы должны добавить туда Спасибо за ваш ответ. Я попытался скопировать строку подключения из проекта, содержащего файл edmx, и поместить его в корневой файл web.config в моем проекте MVC. К сожалению, он все еще не может найти строку подключения. Нужно ли каким-либо образом изменять строку подключения? это наоборот. Во время разработки вам понадобится строка con в app.cofnig в проекте с файлом .edmx. Если у вас есть, может быть, имя не так. Имя строки соединений должно совпадать с именем свойства "имя объекта сущности" в вашем файле .edmx

Добавить ConnectionString в файл MVC Project Web.config

У меня была эта проблема, когда я использую несколько проектов, стартовый проект с web.config и app.config для проекта EntityFramework.

Чтобы избежать этой проблемы, вы должны:

  1. Вам нужна строка подключения в запущенном файле * .config.
  2. Вам необходимо установить DLL EntityFramework в ваши ссылки

Я столкнулся с той же проблемой. Мне не хватало положить строку подключения в автозагрузку проекта, так как я выполняю операцию доступа к данным с другого уровня. также, если у вас нет app.config в вашем проекте запуска, добавьте файл app.config и затем добавьте строку подключения в этот файл конфигурации.

Спасибо, у меня была проблема с загрузкой моего проекта, и он потерял "Startup Project". Ваш ответ напомнил мне, чтобы убедиться, что проект с файлом контекста и app.config был при запуске.

Я получил это, не установив проект в качестве запуска, как указано в другом ответе. Мой вклад в это - когда вы выполняете Add-Migrations и Update-Database, укажите стартовый проект как часть команды в консоли диспетчера пакетов Nuget (не включайте символы '[' или ']', это просто для того, чтобы показать вам, что вы нужно изменить текст, расположенный там на название вашего проекта):

  1. Enable-Миграция
  2. Add-Migrations -StartupProject [имя вашего проекта, которое содержит класс контекста данных]
  3. Update-Database -StartupProject [то же имя проекта, что и выше]

Это должно сделать это.

Таким образом, вы можете включать команды в свои процедуры, и вам не нужно постоянно менять стартовый проект по умолчанию.

Это потому, что ваш контекстный класс наследуется от DbContext. Я полагаю, ваш ctor выглядит так:

name=. следует изменить на имя вашей connectionString

Строка подключения, сгенерированная проектом, содержащим файл .edmx, генерирует строку подключения, это может показаться удержанием файлов вида app.config, которые были скопированы в выходной каталог и на которые ссылается исполняемый файл для хранения информации конфигурации среды выполнения.

Это нарушает работу веб-проекта, поскольку отсутствует автоматический процесс добавления случайной информации .config в файл web.config для веб-проекта.

Проще всего скопировать строку подключения из файла конфигурации в раздел соединений файла web.config и игнорировать содержимое файла конфигурации.

Лучший способ, который я только что нашел, - это временно установить этот проект (скорее всего, библиотеку классов) в стартовый проект. Это заставляет консоль диспетчера пакетов использовать этот проект в качестве источника конфигурации. одна из причин, по которой он настроен таким образом, заключается в модели сверху вниз, которой обычно следуют файлы econfig. Практическое правило заключается в том, что ближайший к клиенту проект (например, приложение MVC) - это файл web.config или app.config, который будет использоваться.

Убедитесь, что вы поместили строку подключения в ROOT web.config запуска проекта.

Я знаю, что в некотором роде заявляю об очевидном здесь, но это случилось и со мной - хотя у меня уже была строка подключения в моем проекте MVC Web.Config (файл .edmx был помещен в другой проект библиотеки классов), и я не мог не могу понять, почему я продолжаю получать исключение . Короче говоря, я скопировал строку подключения в Views \ Web.Config по ошибке, в странной комбинации усталости и отсутствия прокрутки до конца сценарий решения проблемы. Да, такие вещи случаются и с опытными разработчиками :)

Эта проблема возникает, когда вы используете слои в своем проекте и определяете или устанавливаете фрейм Entity в DataLayer и пытаетесь запустить свой проект

Поэтому, чтобы преодолеть эту проблему, скопируйте строку подключения из слоя, где находится файл Edmx, и вставьте строку подключения в основной файл web.config.

Добавьте строку подключения в корневой файл web.config проекта MVC 'container', который ссылается на библиотеку классов следующим образом:

Если вы не хотите использовать «MyEntities» в качестве имени подключения, измените его по своему желанию, но сделайте следующее изменение в своем классе MyEntities DbContext:

Причина этой ошибки: если мы не будем указывать имя строки подключения или строку подключения в производном классе DbConext (в вашем случае это MyEntities), тогда DbContext автоматически выполнит поиск строки подключения в корневом файле web.config, имя которого - то же самое, что и имя производного класса (в вашем случае это My Entities).

У меня была эта проблема при запуске MSTest. Я не мог заставить его работать без флага "noisolation".

Надеюсь, это кому-нибудь поможет. Это стоило мне много времени, чтобы понять это. Все отлично работает из IDE. Что-то странное в Entity Framework в этом контексте.

Регулярные миграции

Есть два варианта - первый, который предложили здесь все, - убедиться, что строка подключения находится в файле Web.config проекта. При работе со строками подключения из параметров приложения Azure это означает, что значения Web.config будут перезаписаны значениями Azure.

Azure или автоматическая миграция (программная)

Существует вторая опция, если вы запускаете миграцию программно, которая позволяет запускать миграции с использованием строки подключения, которая получается динамически (или с помощью параметров приложения Azure), не сохраняя ее в Web.config:

При настройке конфигурации TargetDatabase используйте конструктор DbConnectionInfo, который принимает строку подключения и имя поставщика, а не конструктор, который принимает только имя подключения. Если в строке подключения нет имени поставщика, и вы используете SQL Server / Azure SQL, используйте «System.Data.SqlClient»

Это также может привести к тому, что в вызывающем коде будет недостаточно ссылок на dll. Небольшой неуклюжий взлом может спасти ваш день.

Я следовал подходу DB First и создал файл EDMX в проекте библиотеки классов DAL, который имел ссылку на библиотеку классов BAL, на которую в свою очередь ссылалась служба WCF.

Так как я получал эту ошибку в BAL, я попробовал вышеупомянутый метод, чтобы скопировать детали конфигурации из App.config проекта DAL, но не решил. В конце концов, по совету друга, я просто добавил фиктивный файл EDMX в проект WCF (с соответствующим подключением к БД и т. Д.), Поэтому он импортировал все необходимое, а затем я просто удалил файл EDMX и просто избавился от проблемы с чистая сборка.

На верхний ответ @RyanMann есть комментарий, который предполагает:

Сохраните строки подключения в одном файле конфигурации, а затем назовите их в других проектах <connectionString configSource="../ProjectDir/SharedConnections.config" />

Это фантастическое предложение!

Он также работает для обмена строками соединения между файлами App.config и Web.config!

Любой, кто хочет следовать этому предложению, должен перейти к такому ответу . В нем есть действительно отличное пошаговое руководство по совместному использованию строк соединения между несколькими проектами в решении.

Единственное предостережение заключается в том, что он configSource должен существовать в том же каталоге или подкаталоге. Ссылка выше объясняет, как использовать «Добавить как ссылку», чтобы обойти это.

У меня была эта ошибка при попытке использовать EF в плагине AutoCAD. Плагины САПР получают строку подключения из файла acad.exe.config. Добавьте строку подключения, как указано выше, в файл конфигурации acad, и она работает.

Если вы используете модель MVVM, попробуйте скопировать строки подключения во все части вашего проекта.

Внедрение строк соединения в код приложения может привести к появлению уязвимых мест в системе безопасности и проблем с обслуживанием. Незашифрованные строки подключения, скомпилированные в исходный код приложения, можно просматривать с помощью средства Ildasm.exe (IL Disassembler). Кроме того, после изменения строки соединения необходимо перекомпилировать приложение. По этим причинам рекомендуется хранить строки соединения в файле конфигурации приложения.

Работа с файлами конфигурации приложения

Раздел connectionStrings

Строки подключения могут храниться в виде пар "ключ/значение" в разделе connectionStrings элемента configuration файла конфигурации приложения. Дочерние элементы включают add, clear и remove.

Можно сохранить часть строки соединения в файле конфигурации и для ее дополнения во время выполнения использовать класс DbConnectionStringBuilder. Это удобно в сценариях, в которых заранее неизвестны элементы строки соединения или желательно не сохранять конфиденциальные данные в файле конфигурации. Дополнительные сведения см. в статье Connection String Builders (Построители строк подключения).

Использование внешних файлов конфигурации

Для хранения строк подключения во внешнем файле конфигурации создайте отдельный файл, содержащий единственный раздел connectionStrings. Не следует включать какие-либо дополнительные элементы, разделы или атрибуты. В данном примере показан синтаксис внешнего файла конфигурации.

В основном файле конфигурации приложения для указания полного имени и расположения внешнего файла используется атрибут configSource. В следующем примере применяется ссылка на внешний файл конфигурации с именем connections.config .

Получение строк соединения во время выполнения

Файл machine.config также содержит раздел connectionStrings, включающий строку подключения, используемую Visual Studio. При получении строк подключения из файла app.config приложения Windows с помощью имени поставщика в первую очередь загружаются строки подключений из файла machine.config, затем записи из файла app.config. Добавление ключевого слова clear сразу после элемента connectionStrings приводит к удалению из памяти всех ссылок, унаследованных от структуры данных, поэтому учитываются только строки подключений, определенные в локальном файле app.config.

Работа с классами конфигурации

Для получения строк соединения из файлов конфигурации приложения используется ConnectionStringSettingsCollection. Этот объект содержит коллекцию объектов ConnectionStringSettings, каждый из которых представляет одну запись в разделе connectionStrings. Его свойства сопоставляются с атрибутами строк соединения, что позволяет получить строку соединения, указав имя строки или имя поставщика.

Свойство Описание
Name Имя строки соединения. Сопоставляется с атрибутом name.
ProviderName Полное имя поставщика. Сопоставляется с атрибутом providerName.
ConnectionString Строка подключения. Сопоставляется с атрибутом connectionString.

Пример. Список всех строк соединения

Файл System.Configuration.dll не включается в проекты всех типов, поэтому для использования классов конфигурации может потребоваться сформировать на него ссылку. Имя и расположение файла конфигурации определенного приложения зависит от типа приложения и процесса размещения.

Пример. Извлечение строки соединения по имени

Данный пример демонстрирует способ получения строки соединения из файла конфигурации путем указания ее имени. Код создает объект ConnectionStringSettings, сопоставляя указанный входной параметр с именем ConnectionStrings. Если совпадающее имя не найдено, функция возвращает значение null ( Nothing в Visual Basic).

Пример. Извлечение строки соединения по имени поставщика

В этом примере демонстрируется способ получения строки подключения путем указания неизменяемого имени поставщика в формате System.Data.ProviderName. В коде выполняется итерация по ConnectionStringSettingsCollection и происходит возврат строки соединения для первого найденного ProviderName. Если имя поставщика не найдено, функция возвращает значение null ( Nothing в Visual Basic).

Шифрование разделов файлов конфигурации с использованием защищенной конфигурации

В приведенном ниже фрагменте файла конфигурации показан раздел connectionStrings после шифрования. В разделе configProtectionProvider задается поставщик защищенной конфигурации, который используется для шифрования и дешифрования строк подключения. Раздел EncryptedData содержит зашифрованный текст.

Поставщики защищенной конфигурации

Оба поставщика обеспечивают надежное шифрование данных. Однако, если планируется использовать один файл конфигурации на нескольких серверах, как в веб-ферме, то только RsaProtectedConfigurationProvider позволяет экспортировать ключи шифрования, применяемые для шифрования данных, и импортировать их в другой сервер. Дополнительные сведения см. в разделе Импорт и экспорт защищенных контейнеров ключей RSA для конфигурации.

Использование классов конфигурации

Пространство имен System.Security.Cryptography содержит классы, которые предоставляют дополнительные возможности шифрования и расшифровки данных. Эти классы можно использовать в том случае, если требуются криптографические службы, недоступные с использованием защищенной конфигурации. Некоторые из этих классов являются оболочками для Microsoft CryptoAPI, а другие представляют собой реализации полностью на управляемом коде. Дополнительные сведения см. в разделе Службы криптографии.

Пример App.config

Этот пример демонстрирует переключение шифрования раздела connectionStrings в файле app.config для приложения Windows. В этом примере процедура принимает имя приложения в качестве аргумента, например, «MyApplication.exe». Затем файл app.config зашифровывается и копируется в папку, которая содержит исполняемый файл с именем MyApplication.exe.config.

Строку соединения можно расшифровать только на компьютере, где она была зашифрована.

Читайте также: