У меня есть проект под названием MyApp
, который содержит модели Ядро Entity Framework. Для создать начальную базу данных из этих моделей я использовал следующую команду в Консоль диспетчера пакетов Visual Studio:
dotnet ef migrations -v add InitialCreate
Структура каталогов моего проекта выглядит примерно так:
MyApp
|-bin
| |-Debug
| | |-netcoreapp2.1
| | | |-bin
. . . | |-...
. . . | |-MyApp.dll
. . . | |-...
|-MyApp.deps.json
|-MyApp.runtimeconfig.dev.json
|-MyApp.runtimeconfig.json
Когда я запускаю указанную выше команду для создания исходной базы данных, появляется следующая ошибка:
An assembly specified in the application dependencies manifest
(MyApp.deps.json) was not found:
package: 'MyApp', version: '1.0.0'
path: 'MyApp.dll'
Итак, команде не удалось найти файл MyApp.dll
, который находился в каталоге bin
.
Это видно из следующего подробного вывода:
PM> dotnet ef migrations -v add InitialCreate
Using project 'C:\Users\rohan\Projects\MySolution\myproject\MyApp.csproj'.
Using startup project 'C:\Users\rohan\Projects\MySolution\myproject\MyApp.csproj'.
Writing 'C:\Users\rohan\Projects\MySolution\myproject\obj\MyApp.csproj.EntityFrameworkCore.targets'...
dotnet msbuild /target:GetEFProjectMetadata /property:EFProjectMetadataFile=C:\Users\rohan\AppData\Local\Temp\tmp4BF.tmp /verbosity:quiet /nologo C:\Users\rohan\Projects\MySolution\myproject\MyApp.csproj
Writing 'C:\Users\rohan\Projects\MySolution\myproject\obj\MyApp.csproj.EntityFrameworkCore.targets'...
dotnet msbuild /target:GetEFProjectMetadata /property:EFProjectMetadataFile=C:\Users\rohan\AppData\Local\Temp\tmpEB2.tmp /verbosity:quiet /nologo C:\Users\rohan\Projects\MySolution\myproject\MyApp.csproj
dotnet build C:\Users\rohan\Projects\MySolution\myproject\MyApp.csproj /verbosity:quiet /nologo
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:17.49
dotnet exec --depsfile C:\Users\rohan\Projects\MySolution\myproject\bin\Debug\netcoreapp2.1\MyApp.deps.json
--additionalprobingpath C:\Users\rohan\.nuget\packages --additionalprobingpath "C:\Program Files\dotnet\sdk\NuGetFallbackFolder"
--runtimeconfig C:\Users\rohan\Projects\MySolution\myproject\bin\Debug\netcoreapp2.1\MyApp.runtimeconfig.json
"C:\Program Files\dotnet\sdk\2.1.700\DotnetTools\dotnet-ef\2.1.11\tools\netcoreapp2.1\any\tools\netcoreapp2.0\any\ef.dll"
migrations add InitialCreate
--assembly C:\Users\rohan\Projects\MySolution\myproject\bin\Debug\netcoreapp2.1\MyApp.dll
--startup-assembly C:\Users\rohan\Projects\MySolution\myproject\bin\Debug\netcoreapp2.1\MyApp.dll
--project-dir C:\Users\rohan\Projects\MySolution\myproject\ --language C#
--working-dir C:\Users\rohan\Projects\MySolution\myproject --verbose --root-namespace MyApp
dotnet : Error:
At line:1 char:1
+ dotnet ef migrations -v add InitialCreate
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Error::String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found:
package: 'MyApp', version: '1.0.0'
path: 'MyApp.dll'
В основном, путь к файлу dll
в параметрах --assembly
и --startup-assembly
неверен. Это связано с тем, что генерируется (приведенной выше командой) MyApp.deps.json
содержит следующее:
{
"runtimeTarget": {
"name": ".NETCoreApp,Version=v2.1",
"signature": "..."
},
"compilationOptions": {},
"targets": {
".NETCoreApp,Version=v2.1": {
"MyApp/1.0.0": {
"dependencies": {
...
},
"runtime": {
"MyApp.dll": {}
}
},
...
}
...
}
...
}
Здесь внутри объекта runtime
JSON в MyApp/1.0.0
содержится относительный путь к файлу dll
как MyApp.dll
, тогда как это должно было быть bin/MyApp.dll
.
Что сделать, чтобы в объекте runtime
JSON был прописан правильный путь?
Нет, почему ты так думаешь? Мои лазурные функции действительно малы.
Потому что вам нужна целая форма для управления вызовами вашей базы данных
О, я мог бы использовать SqlClient, но я думал, что ORM облегчит работу.
Да, вы не круты, если вы вручную не пишете sql и не используете ADO.NET. Зачем использовать инструмент, который использует отражение, чтобы сделать это за вас. Кроме того, используйте блокнот. JFC.
У меня была очень похожая проблема. После нескольких часов поиска и экспериментов я нашел этот пост: https://github.com/aspnet/EntityFrameworkCore/issues/14679
Разделение материала базы данных в отдельный проект библиотеки классов, а затем добавление IDesignTimeDbContextFactory исправило это для меня.
Удачи
После долгих исследований я нашел эту работу здесь:
https://dev.to/azure/using-entity-framework-with-azure-functions-50aa
Но нужно было адаптировать его для n-уровневой установки, при которой модели находились в другом проекте (вместе с другими проектами). Мне нужно было скопировать все dll, начинающиеся с «Crank» (кодовое имя функции), а не только dll запускаемого проекта.
Конечным исправлением было добавление следующего к запуску csproj.
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="copy /Y "$(TargetDir)bin\Crank*.dll" "$(TargetDir)Crank*.dll"" /></Target>
Я понимаю, что это скопирует библиотеки DLL проекта, чтобы их можно было использовать для добавления-миграции и обновления-базы данных EF.
Обратите внимание на шаг, необходимый для установки переменной среды также перед запуском add-migration или update-database:
$env:CrankDealershipDatabase="Server=.\ss2016,1433;Database=CrankDealership_Develop;Trusted_Connection=True;MultipleActiveResultSets=true"
Это были пакеты в то время:
Microsoft.Azure.Functions.Extensions 1.0.0
Microsoft.EntityFrameworkCore.SqlServer 2.2.6
Microsoft.NET.Sdk.Функции 1.0.29
Microsoft.EntityFrameworkCore 2.2.6
Microsoft.EntityFrameworkCore.Design 2.2.6
Microsoft.EntityFrameworkCore.Tools 2.2.6
Microsoft.VisualStudio.Web.CodeGeneration.Design 2.2.3
вы впихиваете столько логики в 1 лазурную функцию?