I am trying to understand the difference between the two nuget restore commands in Azure build pipeline:
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
and
- task: DotNetCoreCLI#2
inputs:
command: 'restore'
projects: '$(solution)'
feedsToUse: 'select'
I have tried to understand but at microsoft pages all I see is that one can use both - I can't really find anything stating what the differences are. (I do not really understand the feedsToUse: 'select' statement either)
And, as a second question, what is the difference between the latter and
- task: DotNetCoreCLI#2
inputs:
command: restore
projects: '**/*.csproj'
Given that the solution contains all of the csproj (and only csproj)?
Nuget task is used to install and update NuGet package dependencies, or package and publish NuGet packages. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
dotnet restore internally uses a version of NuGet.exe that is packaged with the .NET Core SDK. dotnet restore can only restore packages specified in the .NET Core project .csproj files. If you also have a Microsoft .NET Framework project in your solution or use package.json to specify your dependencies, you must also use the NuGet task to restore those dependencies.
In .NET Core SDK version 2.0 and newer, packages are restored automatically when running other commands such as dotnet build. However, you might still need to use the .NET Core task to restore packages if you use an authenticated feed.
Regarding feedsToUse: 'select', when the packages cached in Azure Artifacts with upstream sources, you should use feedsToUse: 'select', and specify vstsFeed: xxxx. Check the following syntax (If you want to restore packages from an external custom feed, use feedsToUse: 'config', and specify nugetConfigPath and externalFeedCredentials):
#feedsToUse: # Options: select, config
#vstsFeed: # Required when feedsToUse == Select
#nugetConfigPath: # Required when feedsToUse == Config
#externalFeedCredentials: # Optional
When you don't need packages cached in Azure Artifacts, or from an external custom feed, use the following syntax (You should specify the path to the csproj file(s) to use in projects, not the path to the solution):
- task: DotNetCoreCLI#2
displayName: 'dotnet restore'
inputs:
command: restore
projects: '**/*.csproj'
Useful links:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/ecosystems/dotnet-core?view=azure-devops&tabs=dotnetfive
Related
I have a build pipeline that is building multiple library files in a single solution. In the YML file I have the following task to package the dlls;
- task: DotNetCoreCLI#2
displayName: 'Create nuget packages'
inputs:
command: 'pack'
packagesToPack: 'Framework/**/*.csproj;!**/*.Test.csproj'
packDirectory: '$(Build.ArtifactStagingDirectory)/packages/nuget'
nobuild: true
versioningScheme: 'byBuildNumber'
This creates all my library files as seperate nupkg files. I would like them in one nupkg file.
Is this possible using dotnet pack?
One of the way of doing that is to create a nuspec that includes outputs of the csproj you want to bundle since the pack command only accepts a single project.
You can also use the dependencies attribute to link to other nupkg instead of bundling them.
I created a pipeline using the .NET desktop template and using the 'create .msi' extension but it shows a warning:
##[warning]No .MSI files were found, please check your build-configuration. If this is expected, you might consider to use the default Visual Studio Build task instead of this custom Installer task.
2018-11-28T22:58:54.1434410Z ##[section]Finishing: Create .msi file(s) from VS Installer project(s).
Anyone know how can I achieve creating an exe file using an Azure Pipeline and deploy it on a Virtual Machine.
If you use .NET Core CLI task to build your console app.
Below dotnet publish arguements commmand will generate .exe file. See this thread for more information.
dotnet publish -r win-x64 -p:PublishSingleFile=True --self-contained false
So you can add above arguments to your .NET Core CLI task. See below yaml pipeline.
- task: DotNetCoreCLI#2
inputs:
command: publish
arguments: -r win-x64 -p:PublishSingleFile=True --self-contained false -o $(Build.ArtifactStagingDirectory)
projects: '**/*.csproj'
publishWebProjects: false
enabled: true
Above DotNetCoreCLI task will output the .exe file to folder $(Build.ArtifactStagingDirectory) (ie. C:\agent\_work\1\a)
If you use Visual Studio Build task to build your console app.
You can first add below <PublishSingleFile> and <RuntimeIdentifier> properties to the .csproj file of your project.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<PublishSingleFile>True</PublishSingleFile>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
Then set the msbuildArgs of the Visual Studio Build task in your pipeline as below:
- task: VSBuild#1
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
msbuildArgs: '/t:publish /p:PublishSingleFile=True /p:RuntimeIdentifier=win-x64 /p:outputpath=$(Build.ArtifactStagingDirectory)\'
Then Vsbuild task will output the .exe file to folder $(Build.ArtifactStagingDirectory) specified in /p:outputpath (ie. C:\agent\_work\1\a)
I have one repository with 3 branches dev, test and prod. I have a Visual Studio solution with 3 projects in it. One Angular, a worker service and ASP.NET web api project. So that whole solution in one repository.
I have pushed everything to dev branch. So when creating the build pipeline I chose ASP.NET core and then on writing the build yaml, in the trigger I specified Dev branch
trigger : - dev
But how can I specify which project to build among the 3 project in that repository to build? My plan is to build the ASP.NET core web api to build.
Also I need another build for the angular as well..
This will be in your build task:
steps:
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: build
projects: '**/*.csproj' # Update this to match your need
arguments: '--configuration $(buildConfiguration)'
The project path will be different for your various projects
I have searched everywhere all day long trying to get this pipeline to work.
It starts the pipeline and my tasks seem to run fine right up until I hit nuget restore for my solution. It fails with:
Unable to locate executable file: 'mono'
I have no idea why this is happening. I am using the macOS-latest vm image and I am using this task to set the mono version:
- task: Bash#3
inputs:
targetType: 'inline'
script: |
SYMLINK=6_8_0_123
MONOPREFIX=/Library/Frameworks/Mono.framework/Versions/$SYMLINK
echo "##vso[task.setvariable variable=DYLD_FALLBACK_LIBRARY_PATH;]$MONOPREFIX/lib:/lib:/usr/lib:$DYLD_LIBRARY_FALLBACK_PATH"
echo "##vso[task.setvariable variable=PKG_CONFIG_PATH;]$MONOPREFIX/lib/pkgconfig:$MONOPREFIX/share/pkgconfig:$PKG_CONFIG_PATH"
echo "##vso[task.setvariable variable=PATH;]$MONOPREFIX/bin:$PATH"
Is there something else I can set to make Nuget find the mono library?
Thanks.
Azure Pipeline for Xamarin Forms iOS Fails at Nuget Restore
According to the error message:
Unable to locate executable file: 'mono'
It seems the NuGet task hasn't been implemented to work on that agent (macOS-latest) at this moment.
To resolve above error, we could use the .NET Core (dotnet restore) task instead of nuget restore task.
The final solution for this specific case:
Thanks to jmichas for sharing. Use the .NET Core (dotnet restore) task indeed resolve that error. But, it brought an onslaught of other errors in specific case. The final solution for this specific case is that use the runNugetRestore in the xamarin ios build task:
- task: XamariniOS#2
inputs:
runNugetRestore: true
Hope this helps others.
I am trying to replicate the following Azure pipeline using the CLI dotnet command:
- task: DotNetCoreCLI#2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
So far, I can make the project build, but getting a zip file out of it seems problematic - passing the inputs zipAfterPublish etc appears impossible to pass, although, there is some scattered documentation suggesting these can be passed with -p:"optiona=x;optionb=y" or /p:"optiona=x;optionb=y". I can find no definitive documentation on this.
This is what I have - the build part works, the $PWD/out directory is populated with many files but nothing is zipped:
dotnet publish --configuration Release --output $PWD/out /p:"zipAfterPublish=true;publishWebProjects=true"
I'm guessing this is around how to pass the inputs ( https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops ) correctly to the command.
I am trying to replicate the following Azure pipeline using the CLI
dotnet command:
1.The zipAfterPublish is one option available only in Dotnet Publish task. If you check the log of dotnet publish task, you'll find it doesn't pass any property like zipAfterPublish to the command:
Since only the msbuild property can be passed in this way: /p:xxx=xxx. The zipAfterPublish won't work in command-line as it's not msbuild property, that option is not supported in dotnet cli, only available in Azure Devops Dotnet Publish task.
2.Normally if we want to publish one .net core web project and zip it after publish using dotnet cli locally, we can use command like:
dotnet publish xx.csproj /nologo /p:PublishProfile=xxx /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /maxcpucount:1 /p:platform=xxx /p:configuration=xxx /p:DesktopBuildPackageLocation=SomePath\xxx.zip
Or
dotnet build xxx.sln /nologo /p:PublishProfile=Release /p:PackageLocation="C:\Some\Path\package" /p:OutDir="C:\Some\Path\out" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /maxcpucount:1 /p:platform="Any CPU" /p:configuration="Release" /p:DesktopBuildPackageLocation="C:\Some\Path\package\package.zip"
Which is described in this issue.
Above commands can work in windows to generate a xx.zip folder.
However:
It seems that you're in linux environment, please check this document. If you want to zip the publish folder(generate a package), the dotnet build/publish will call msdeploy.exe to do this job, but since MSDeploy lacks cross-platform support, the following MSDeploy options are supported only on Windows. So dotnet cli command is not supported to generate zip after publish in linux environment... What you want is not supported for now in Linux.
Possible workaround:
Since we can use dotnet publish to publish the project to one folder(Folder works cross-platform), we can call another zip command after dotnet publish to zip it ourselves.
Hope my answer helps to resolve your puzzle :)