![]() We run our builds on the win-2019 agent and have not tested this on any of the Linux based ones. NET Core is multi platform, so you should be able to run the commands on any of the Microsoft hosted build agents in Azure DevOps. System.ArgumentNullException: Value cannot be null. We did not want any hard coded connection strings in the repository and all our app settings are coming from either a Keyvault or the App settings of the Azure Web App, so while I was successful in creating the migration scripts locally, the absence of a connection string caused some issues in running the same command on the Azure DevOps hosted agent. ![]() When it is spelled out, it seems very obvious, but this took me a while to figure out. What the documentation does not directly mention is that to create the required DbContext, a connection string is required to be given and that Program.BuildWebHost is implicitly called with an ASPNETCORE_ENVIRONMENT setting of "development" as discussed in this issue. ![]() In our solution the DbContext is tried to be created from Application Services, as described in the documentation linked above. This command also builds the project by default, so you may opt to use -no-build as well. And most importantly the -idempotent flag to make sure the script can be run multiple times. In short, we specify the startup project path and if needed, project path with -project (both default to the folder where the script is run), then the name of the context, configuration and where to place the script. More specifically this command: dotnet ef migrations script -startup-project -Context -Configuration -output -idempotent Obviously, Migrations commands are what we need. In most cases, it is desirable that the DbContext thereby created is configured in a similar way to how it would be configured at run time. Quoting MS Documentation: Some of the EF Core Tools commands (for example, the Migrations commands) require a derived DbContext instance to be created at design time in order to gather details about the application's entity types and how they map to a database schema. This was fairly straightforward on paper, but in our situation turned out to include some gotchas I was not aware of before. We wanted to keep the concerns separate and instead generate migration scripts in our build steps and then separately run them against our SQL database in the release pipeline. Some people suggest to let the app apply the migrations at runtime, but this might not be the best option to take if you're not running a database local to the app itself. There are multiple schools of thought about when and how should SQL migrations be run during the release process.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |