Problem Background:
I have a class library project that contains the database migrations (MyProject.MigrationProject.csproj). And in startup.cs of the entry project (Web API), I have explicitly included migration assembly like following.
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
configuration.GetConnectionString("DefaultConnection"),
x => x.MigrationsAssembly("MyProject.MigrationProject")));
Then I run the dotnet ef migration command locally using powershell. The command I'm using is:
dotnet ef migrations script --no-build -o D:\migrations\script.sql --idempotent --project D:\...\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj --startup-project D:\...\src\MyProject.WebApi\MyProject.WebApi.csproj
The above command executes successfully on my machine and creates the desired script.sql file on output location. The same command is then used in the build pipeline (using command line task) in Azure Devops but for some reason it fails there. The command on Devops looks like this:
dotnet ef migrations script --no-build -o $(Build.ArtifactStagingDirectory)\migrations\script.sql --idempotent --project $(Build.SourcesDirectory)\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj --startup-project $(Build.SourcesDirectory)\src\MyProject.WebApi\MyProject.WebApi.csproj
The Error I get from Devops:
Script contents:
dotnet ef migrations script --no-build -o D:\a\1\a\migrations\script.sql --idempotent --project D:\a\1\s\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj --startup-project D:\a\1\s\src\MyProject.WebApi\MyProject.WebApi.csproj
##[debug]AGENT_VERSION: '2.193.1'
##[debug]AGENT_TEMPDIRECTORY: 'D:\a\_temp'
##[debug]Asserting container path exists: 'D:\a\_temp'
##[debug]Asserting leaf path exists: 'C:\Windows\system32\cmd.exe'
========================== Starting Command Output ===========================
##[debug]Entering Invoke-VstsTool.
##[debug] Arguments: '/D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\37fc4a71-a144-4332-9a84-04e6138a2538.cmd""'
##[debug] FileName: 'C:\Windows\system32\cmd.exe'
##[debug] WorkingDirectory: 'D:\a\1\s'
"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\37fc4a71-a144-4332-9a84-04e6138a2538.cmd""
An error occurred while accessing the Microsoft.Extensions.Hosting services. Continuing without the applicgation service provider. Error: A certificate with the thumbprint 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' could not be found.
Unable to create an object of type 'ApplicationDbContext'. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728
##[debug]Exit code: 1
##[debug]Leaving Invoke-VstsTool.
##[error]Cmd.exe exited with code '1'.
##[debug]Processed: ##vso[task.logissue type=error]Cmd.exe exited with code '1'.
##[debug]Processed: ##vso[task.complete result=Failed]Error detected
##[debug]Leaving D:\a\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.182.0\cmdline.ps1.
Finishing: CmdLine
At times, by tweaking the YAML file, I was able to get rid of the first error but the 2nd one never disappeared on devops. The issue is pretty much because of having separate project for Migrations but I think that's how it should be...
My Build pipline's YAML:
trigger:
- develop
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: DotNetCoreCLI#2
displayName: Restore
inputs:
command: restore
projects: '**/MyProject.WebApi.csproj'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
projects: '**/MyProject.WebApi.csproj'
arguments: '--no-restore'
- task: DotNetCoreCLI#2
displayName: Test
inputs:
command: test
projects: '**/*[Tt]ests/*.csproj'
arguments: '--no-restore --no-build'
- task: DotNetCoreCLI#2
displayName: 'Publish WebApi'
inputs:
command: publish
publishWebProjects: false
projects: '**/MyProject.WebApi.csproj'
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory) --runtime -r $(runtime)'
- task: CopyFiles#2
inputs:
Contents: '**'
TargetFolder: '$(Build.ArtifactStagingDirectory)'
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: '5.x'
- task: DotNetCoreCLI#2
displayName: Install dotnet-ef
inputs:
command: 'custom'
custom: 'tool'
arguments: 'install --global dotnet-ef --version 5.0.10 --ignore-failed-sources'
- task: CmdLine#2
inputs:
script: dotnet ef migrations script --no-build -o $(Build.ArtifactStagingDirectory)\migrations\script.sql --idempotent --project $(Build.SourcesDirectory)\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj --startup-project $(Build.SourcesDirectory)\src\MyProject.WebApi\MyProject.WebApi.csproj
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
My Suspicion:
It could be an issue with the directory where the command is executed from (on ADO powershell). I suspect this because, on my local machine, before calling the method x.MigrationsAssembly("MyProject.MigrationProject"), the following command failed when I executed it from a directory other than the entry project's directory but when I navigated the powershell to entry project and executed the same command, it went successful. The command at that time was:
dotnet ef migrations script -o D:\migrations\script.sql --idempotent --project D:\...\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj
I'm already using the same YAML in another project but that contains everything in single Web API project and so, I do not get any issue there.
Question:
What am I doing wrong here? What can I do to fix this issue? Any help would be appreciated.
Project Details
DotNet 5.0
EntityFramewokCore 5.0.10
Visual Studio 2019
If I'm missing anything, please ask.
Updates:
My suspicion about working directory for executing the dotnet ef command appears to be wrong as I tried that by supplying workingDirectory parameter to the command line tasks. It works on local machine though.
Thanks #jane-ma-msft
The Error message shows that it is a Certificate error. Please follow the work around to fix the issue.
Try to generate a new certificate or cancel certificate validation.
Check your .sln file. If it has PackageCertificateKeyFile & PackageCertificateThumbprint please try to remove the properties and restart a pipeline.
Or Check that it is configured correctly and that you have uploaded the correct certificate file to the appropriate path.
Make sure that the agent windows-latest has all the .NET SDK versions you need and all the software your project needs to reference. If not, use the task or command line to download them. Click this link to view the software installed on the windows-latest agent.
If you are using the Microsoft-hosted Windows agents in your pipeline, please try to use the self-hosted Agent in your pipeline. Click this document for detailed steps.
Refer here Link 1 & Link 2
Related
I have the following task:
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'XXX'
arguments: '-c "Release" /p:Platform="x64"'
and I want to set the outputpath of the build so that I can publish an artifact after compiling.
/p:OutputPath="$(build.artifactStagingDirectory)\XXX"
But when I specify the output directory (--output $(Build.ArtifactStagingDirectory)\X') I get an error MSB3073
If I remove the output argument it works.
How can I build correctly so that I can publish the artifact or solve the output issue?
If you don't specify the output directory when compiling, the project will compile and place the bin folder in the subfolder of the project. This is the same behavior if you were to compile the solution locally. So you could publish the artifact from that folder:
- publish: '$(Build.SourcesDirectory)\path-to-my-project\bin\'
artifact: myArtifact
For .NET core projects, the command syntax for dotnet build is:
dotnet build [options] <project | solution>
The syntax for the output directory is -o <directory> or --output <directory>. The important detail here is you need to wrap the output directory in quotes and additional msbuild parameters are specified as -p:<param>="value"
Fun tip, you can use the > operator in YAML to represent multi-line strings, so you could represent your task this way:
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'XXX'
arguments: >
-c "Release"
-p:Platform="x64"
-o "$(Build.artifactStagingDirectory)\XXX"
Also note, this being .NET Core, if you're using a Linux build agent, you'll need to use backslashes ('/') for the file path.
Have you tried adding it to the arguments?
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'XXX'
arguments: '-c "Release" /p:Platform="x64" /p:OutputPath="$(build.artifactStagingDirectory)\XXX"'
I have AzureDevops pipeline to build and test my .net core Azure Functions solutions. Locally tests are working fine but they do fail on build Agent(I tried different agents)
Here is error log:
##[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
##[error]Dotnet command failed with non-zero exit code on the following projects : C:\BuildAgent\_work\20\s\UnitTestProject\UnitTestProject.csproj
##[section]Finishing: Test
Error:
Here is my yaml file:
trigger:
- dev
pool: 'SelfHosted'
variables:
workingDirectory: '$(System.DefaultWorkingDirectory)/'
steps:
- task: DotNetCoreCLI#2
displayName: Restore
inputs:
command: 'restore'
projects: '**/*.csproj'
feedsToUse: 'select'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--output $(System.DefaultWorkingDirectory)/publish_output --configuration Release'
- task: DotNetCoreCLI#2
displayName: Test
inputs:
command: 'test'
projects: '**/*.csproj'
publishTestResults: false
Please suggest, thanks in advance!
When investigating above cs0579 duplicate AssemblyInfo error. It is probably because the test process provides assembly information separately and another AssemblyInfo.cs file get generated, which caused the duplication.
You can try below to make sure these assembly information is declared only once in your project.
1, Removing the AssemblyInfo.cs file from your project to prevent the duplication conflict.
2, you can try adding below lines to your .csproj files
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
Please check this similar thread for more possible fixes
I faced similar issue with my automation code's Build pipeline with CI. I was using ".Net Core" task for test execution.
Solution:
I switched my "test" execution task from .Net Core to "Visual Studio test".
In VSTest task under "Test files" i specified exact project name which contains Test Cases. Instead of main solution.dll. As shown in image.
I'm trying to build a dotnet core application via Azure DevOps. I want my assemblies to be versioned with the build number.
In .csproj file:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
<Version>0.0.1</Version>
</PropertyGroup>
The yaml build pipeline contains:
trigger:
branches:
include:
- master
pool:
name: 'Hosted Windows 2019 with VS2019'
#vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
Version.Revision: $[counter(format('{0:yyyyMMdd}', pipeline.startTime), 0)]
VersionMajor: 0
VersionMinor: 1
name: '$(VersionMajor).$(VersionMinor).$(Date:yy)$(DayOfYear).$(Version.Revision)'
steps:
- task: DotNetCoreInstaller#0
inputs:
version: '2.2.300'
- script: dotnet build --configuration Release /p:Version=$(Build.BuildNumber)
displayName: 'dotnet build $(buildConfiguration) $(Build.BuildNumber)'
In the Azure Devops build log the command seems to pick up the correct version:
dotnet build --configuration Release /p:Version=0.1.19185.10
But when I download the artifacts and verify the dlls they still contain version number 0.0.1
Executing this command locally does add the version number in the dll. So, why is the version not added via Azure DevOps?
Unless you tell it otherwise dotnet publish will cause a recompile before publishing files, and thus overwrite anything you've previously tried to acomplish with dotnet build. You use the --no-build flag to supress the compile. Note that --no-build will also set --no-restore so you need to call dotnet restore explicitly. A typical set of commands (with typical variables you might see in Azure DevOps) might be:
dotnet restore
dotnet build --configuration $(BuildConfiguration) --no-restore /p:Version=$(Build.BuildNumber)
dotnet publish --configuration $(BuildConfiguration) --no-build --output $(Build.ArtifactStagingdirectory)
See this blog post for more details.
On Azure DevOps, I want to configure the .NET Core CLI task so that it executes restore with runtime win-x86.
I tried this configuration:
- task: DotNetCoreCLI#2
displayName: 'Restore NuGet'
inputs:
command: 'restore'
projects: './src/MySolution.sln'
feedsToUse: 'config'
nugetConfigPath: './NuGet.config'
arguments: '--runtime win-x86'
...which I thought would add --runtime win-x86 to the executed command. However, the command that gets executed...
/usr/bin/dotnet restore /home/vsts/work/1/s/./src/MySolution.sln --configfile /home/vsts/work/1/Nuget/tempNuGet_158.config --verbosity Detailed
...is missing the runtime option.
On Azure DevOps, is is possible to execute the .NET Core CLI task so that it executes restore with runtime win-x86?
I first tried to determine if there was something wrong with the documentation of the .NET Core CLI task by creating this issue, but it was closed without any dialog, and I was essentially told to post my question on SO instead.
I don't know why, but it look like the version 2 of the task DotNetCoreCLI can't take another arguments in the restore command.
Switch the version to 1 - DotNetCoreCLI#1 and it will work:
I have a repository which has nothing on master, except the Readme and azure-pipelines.yml YAML. On the development branch (the branch I want to build and deploy and have CI on) there are three folders, MVC, Test, and Console, each containing a project (an MVC version of an ASP.NET Core MVC, .NET Core console, and Xunit test project). I want to run dotnet restore and build on the MVC project, but I get the error:
2019-02-08T15:09:20.9373945Z ##[section]Starting: CmdLine
2019-02-08T15:09:20.9468192Z ==============================================================================
2019-02-08T15:09:20.9468291Z Task : Command Line
2019-02-08T15:09:20.9468353Z Description : Run a command line script using cmd.exe on Windows and bash on macOS and Linux.
2019-02-08T15:09:20.9468441Z Version : 2.146.1
2019-02-08T15:09:20.9468490Z Author : Microsoft Corporation
2019-02-08T15:09:20.9468565Z Help : [More Information](https://go.microsoft.com/fwlink/?LinkID=613735)
2019-02-08T15:09:20.9468629Z ==============================================================================
2019-02-08T15:09:22.4499876Z Generating script.
2019-02-08T15:09:22.5206191Z ##[command]"C:\windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\21484123-df40-47c7-9383-7f526daaa124.cmd""
2019-02-08T15:09:22.8173263Z MSBUILD : error MSB1009: Project file does not exist.
2019-02-08T15:09:22.8173430Z Switch: MVC
2019-02-08T15:09:23.1247189Z Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
2019-02-08T15:09:23.1308513Z Copyright (C) Microsoft Corporation. All rights reserved.
2019-02-08T15:09:23.1308642Z
2019-02-08T15:09:23.1308714Z MSBUILD : error MSB1009: Project file does not exist.
2019-02-08T15:09:23.1308801Z Switch: MVC
2019-02-08T15:09:23.2993350Z ##[error]Cmd.exe exited with code '1'.
2019-02-08T15:09:23.3158684Z ##[section]Finishing: CmdLine
The YAML file in master is the following:
# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml
trigger:
- dev
- master
pool:
vmImage: 'vs2017-win2016'
#- task: DotNetCoreInstaller#0
# inputs:
# version: '2.2.103' # replace this value with the version that you need for your project
steps:
- script: |
dotnet restore MVC
dotnet build MVC
- task: PublishBuildArtifacts#1
- script: |
echo Add other tasks to build, test, and deploy your project.
echo See https://aka.ms/yaml
displayName: 'Run a multi-line script'
- task: PublishBuildArtifacts#1
Is there a way to access MVC for the dotnet commands?