I'm developing a project using asp.net core, Entity framework code first, am trying to run EF migrations as a release step, i was advised to use migrate.exe, yet as far as i knew ef asp.net core doesn't generate migrate.exe file.
Am currently using the below command in the release step. After adding the ef core project's bin folder to the generated artifacts.
Command:
dotnet exec
--runtimeconfig ./HOST.runtimeconfig.json
--depsfile ./HOST.deps.json Microsoft.EntityFrameworkCore.Design.dll
--assembly ./DB_CONTEXT_DLL.dll
--startup-assembly ./HOST.dll --data-dir ./
--root-namespace DB_CONTEXT_NAMESPACE
--verbose database update --context DB_CONTEXT_CLASS -e development
The command step fails with the error:
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'd:\a\r1\a{Publish articats folder}\drop\EF\bin\release\netcoreapp1.1\'.
Am not sure what is the hostpolicy.dll and how to generate it as it isn't generated in the bin folder for the EF core project
Any advice?
You can do Entity framework migration during the deploy process. Simple steps:
Create a publish profile (e.g. Web Deploy package, right click project=>Publish)
General deploy package through Visual Studio Build task with /p:DeployOnBuild=true /p:PublishProfile=[profilename];DesktopBuildPackageLocation="$(build.artifactstagingdirectory)\WebAppCoreEF.zip" arguments
Add deploy task (e.g. Azure App Service Deploy) to deploy this package (You can do it in release)
Related
I'm developing a project on Mac. The solution has multiple projects with in it, Domain, WebPortal and API.
From within the WebPortal project I've created a migration by running the following command from within that project;
dotnet ef migrations add ApplicationUser_Deactivate -o ../SolutionName.Domain/data/migrations
This has created the migration files within the Domain project.
The problem is, running the command dotnet ef database update doesn't appear to pickup the migration files from that location and I can't seem to find a way to tell the command where the migration files are.
Is there a way to do this?
Please try
dotnet ef database update --project .SolutionName.Domain/data/migrations or
dotnet ef database update --p SolutionName.Domain
Argument p, project - Relative path to the project folder of the target project. Default value is the current folder.
I am beginner to A and just starting to work in it
What task I must add in project ASP.NET CORE to Azure DevOps Pipelines to pass the build number from the azure devops pipeline to the project code
Client.Shell.csproj:
<MinimumRequiredVersion> 4.60.0825.700 </MinimumRequiredVersion>
<ApplicationRevision> 716 </ApplicationRevision>
<ApplicationVersion> 4.60.0825.% 2a </ApplicationVersion>
https://i.stack.imgur.com/BXyHm.png
You can do something like this, Replace "1.2.3" with your build parameter.
dotnet publish ./MyProject.csproj /p:Version="1.2.3" /p:InformationalVersion="1.2.3-qa"
Look at this https://github.com/dotnet/docs/issues/7568
When a pipeline runs, it usually performs get sources action first. So you just need to map the correct project path, then the pipeline will get entire project to the Agent's working folder.
To update the version in .csproj file, and to pass the build number from the azure devops pipeline, you can check Assembly Info extension, and use the variable $(Build.BuildNumber) in the version field.
This extension can update project AssemblyInfo files and .Net Core / .Net Standard project files .csproj. For detailed instructions on how to configure the extension please see the following link:
https://github.com/BMuuN/vsts-assemblyinfo-task/wiki/Versioning
If you want to update the file in repo, you still need to run git push command to push the changes to the repo.
I have NET Core 3.1 application where my [models,dbcontext,application] are all in their own assemblies.I am trying to issue a migration(s) for the application.I keep getting this error:
$ dotnet ef migrations add InitialCreate --project DataAccess
MSBUILD : error MSB1009: Project file does not exist. Switch:
DataAccess Unable to retrieve project metadata. Ensure it's an
MSBuild-based .NET Core project. If you're using custom
BaseIntermediateOutputPath or MSBuildProjectExtensionsPath values, Use
the --msbuildprojectextensionspath option.
Current Structure
*root
-App (.NET Core 3.1)
-DataAccess (.NET Standard 2.1) (Contains the DBContext)
-Models (.NET Standard 2.1) (contains models)
I have also tried creating a separate assembly for migrations and use the MigrationAssembly extension in my App :
services.AddDbContext<[some DBContext]>(x => x.UseSqlServer([some string],x=>x.MigrationsAssembly("Migrations")));
Tried Structure
*root
-App
-Migrations (.NET Standard 2.1)
-DataAccess (.NET Standard 2.1)
-Models (.NET Standard 2.1)
I do not understand how this should be done.I want to be able to do migrations and ideally i would like to keep them in their own assembly.Currently i can't do them at all.
P.S I have also tried adding this to my App csproj file:
<GenerateRuntimeConfigurationFiles>True</GenerateRuntimeConfigurationFiles>
the answer given by #Ajay above finally worked for me, after days and days googling for it:
to insert the migrations assembly complete path in the --project argument, like this:
dotnet ef migrations add Mymigration --project "c:\repos\myproject\Data"
...and you should execute this command from your main startup project (like c:\repos\myproject\Web)
exactly same issue here, since hours, good to know not being the only one getting crazy about!
Finally worked it out:
I'm using EFCore.Tools in Package Manager Console instead of dotnet Cli:
//Add Migration
Add-Migration *name* -Project *Library project* -StartupProject *StartUp/Web project*
//Update Database
Update-Database -Project *Library project* -StartupProject *StartUp/Web project* -verbose
i would go this direction... have fun!
First change directory to project directory, then add .csproj
$ dotnet ef migrations add InitialCreate --project DataAccess.csproj
I hope it works!
I used the full Directory path and it's worked. And also we should use correct project references.
ex: dotnet ef migrations add Initial --project D:\NK-Pro\API\TaskAPI.DataAccess\TaskAPI.DataAccess.csproj
The CI pipeline works well if I remove the nobuild:true option from the DotNetCoreCLI#2 task to pack the Project (ie to create a NuGet package) but I am not able to understand what special except not building the project does the nobuild option brings.
I need not want to build the Project again as the Previous task have already build the Project and locked the Assembly version of DLLs generated. I want to use the same build to create the NuGet package and to do the same I need to pass the NoBuild option but doing the same breaks the pipeline.
The pipeline gives the error that the DLLs to be packed are not present at the specified location but I tried to look at the location and I could find the DLLs.One thing that confuses me is that though I have given nobuild to be true but still the tasks shows as Building the Project.
- task: DotNetCoreCLI#2
displayName: ".NET pack"
inputs:
command: pack
packagesToPack: ${{ parameters.packagesToPack }}
nobuild: true
versioningScheme: byEnvVar
versionEnvVar: CI_Version
packDirectory: $(build.artifactStagingDirectory)\${{ parameters.packTo }}
verbosityPack: 'Normal'
Its also important to note that the same thing( nobuild:true) works on Windows Agent but it fails on Ubuntu Agent.
PS: It could be a case where windows has upgraded the agent and has caused the issue. I searched over the issue and found that one has to lock the .net SDK in the build pipeline
Thanks for the other answers that may be related to the issue but things were already taken care.
The issue was only on the Linux Environment because of an issue in .NET SDK. Refer here
The error(DLLs could not be found in the path specified ) that was being generated was correct in somehow but also it was misleading. The DLLs were being generated in Release folder at the build stage and when I was packing the DLLs they were being searched in release folder.
Though Release and release remains the same in Windows Environment but Ubuntu being case sensitive generates the Error.
The SDK implementation of .Net Core missed the IgnoreCase in the Regex option and that caused the build to break on switchin to a Linux Agent.
DotnetBuild:
Dotnet Pack:
Solution: Define the folder where to generate the DLLs in the .csproj and the automatically build and pack step would pick the DLLs from there.
For this error NU5026 ,it refers to the project being packed has not been built yet and hence cannot be packed. Please view this reference.
The file ''F:\project\bin\Debug\net461\project.exe' to be packed was not found on disk.
According to your description, you canceled the automatic build before pack. There's possibility that your build task and pack task did't run with same configuration. For example, In dotnet build task, the project is automatically built with Debug configuration, and in the pack task you set the configuration as Release.
In dotnet build task, the project is automatically built with Debug configuration.
In the dotnet pack task , the default Configuration to Package is Release
If you do not cancel the automatic build before pack, in the .net pack task the project is built in Release configuration.
So please check the log of your build task and pack task, make sure the dotnet build command and dotnet pack command use the same configuration.
I was trying to configure a simple pipeline to build and deploy my asp.net core application into shared hosting, however it always failed in restoring Newtonsoft.Json, dispute the project is build-able and fully works on local machine, my ci file looks like the following:
image: microsoft/dotnet:latest
stages:
- build
before_script:
- dotnet restore -s https://api.nuget.org/v3/index.json --packages ./.nuget/
build:
stage: build
script:
- "dotnet build"
And the error I am getting inside the pipeline is:
/usr/share/dotnet/sdk/2.1.402/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Newtonsoft.Json". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
I also tried dotnet restore only, but with the same result.
I figure out the problem, I added the Newtonsoft.Json as reference instead of installing it from nuget (actually visual studio added it as reference for me from the quick action), so I remove the reference and install it as package and everything works perfectly