Specify MSBuild Version in DotNetCoreCLI Task in Azure Pipeline - .net-core

I am using a DotNetCoreCLI task to build a project. But I would like to build it with MSBuild 16.0 what seems to be not possible so far. Here are the facts (snippet from Azure Pipelines Yaml):
pool:
vmImage: 'windows-2019'
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
projects: '$(BuildProjectFilter)'
arguments: '--configuration $(BuildConfiguration) -:Platform=$(BuildPlatform) -p:VisualStudioVersion=16.0 -p:tv=16.0'
No matter what I try the dotnet build command always uses ToolsVersion 15.0:
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.156.1
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
[command]C:\windows\system32\chcp.com 65001
Active code page: 65001
[command]"C:\Program Files\dotnet\dotnet.exe" build d:\a\1\s\src\xxx.csproj --configuration release -p:Platform=x64 -p:VisualStudioVersion=16.0 -p:tv=16.0
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
If I only supply the -tv:16.0 switch MSBuild complains:
MSBUILD : error MSB1040: ToolsVersion is not valid. The tools version "16.0" is unrecognized. Available tools versions are "15.0".
If I supply -p:VisualStudioVersion=16.0 -p:tv=16.0 in combination the Error is recognized later by Fody telling me
Fody is only supported on MSBuild 16 and above. Current version: 15.
Of course, downgrading Fody might be a solution. But I would prefer to use MSBuild 16 as it should be available in this vm image. Is there a way to achieve that?

I think you'd better specified the higher version of .NET core SDk 2.2.401 in your task.
If I use SDK 2.2.101 to build project, I will receive the same error message with you:
To explain this, you can see the below content which mentioned in the doc:
If the .Net Core SDK version you used is lower than 2.2.401, since these lower version SDK could not be compatible with VS2019. At this time, even you specified VS 2019, it will still use the build engine which belong to VS2017. That's why in your first error log, the build engine this pipeline used is 15.9.20+g88f5fadfbe
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
As test, after I build project with the .Net Core SDK which version is 2.2.401, as the below pic you see:
The MSbuild version it took is 16. So, it satisfied the definition of the underlying fody file:
This is part of the underlying fody file. You can see, it is defined as only your MSbuild version is 16, or it will throw the error message like you received.
So, to solve your issue, I recommend you try with specifying the .Net Core SDK as 2.2.401 or above version in the task.

Related

Can I publish targeting linux-armv6 runtime in .NET Core 7?

According to this issue and this runtime list for .NET Core v7.0, linux-armv6 is supported. However, when I try to target it with dotnet publish -r linux-armv6 I get the following error:
C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(135,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'linux-armv6'.
What am I doing wrong?
armv6 in dotnet is only community supported. You can build it by yourself. If you want, I've build it from 7.0.0 source and put it in docker image for building my project. (I use linux-armv6/self contained)
https://hub.docker.com/r/taphome/dotnet7armv6
From my experience, dotnet is working pretty well on armv6. Problem is if you have some Nugets with native libraries which probably doesn't have armv6 version of native dependencies. I switched my app.libraries from mono/netstandard20 to net7 on armv6.

How do I get Azure DevOps to build a .NET 4.8 app?

When we run dotnet build on a .net 4.8 app, we get an error message. I attempted to install the developer pack for 4.8. However, that fails and I think the reason it fails is that .NET 4.8 is already installed on the system. What's the right way to resolve this issue?
##[error]C:\Program Files\dotnet\sdk\6.0.300\Microsoft.Common.CurrentVersion.targets(1221,5): Error MSB3644: The reference assemblies for .NETFramework,Version=v4.0 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks
Is it that we cannot use dotnet build for 4.8 apps? Do we need to use MSBuild instead?
It requires the build agent be windows based, e.g. vmImage: 'windows-2022'.
- task: VSBuild#1
displayName: 'Dotnet build'
inputs:
solution: '*.sln'
msbuildArgs: '/t:build /p:DeployOnBuild=true /p:OutputPath="$(Build.ArtifactStagingDirectory)"'
restoreNugetPackages: true
configuration: '$(buildConfiguration)'
The above assumes the solution file is located in the root of the source repository.
While restoreNugetPackages is optional I received package not found errors until enabling it.

Cannot push dotnet 3.0.100 app to Octopus from Azure DevOps

I’m using the DevOps pipeline to push my dotnet build to an Octopus cloud instance.
It worked fine until I added the dotnet SDK 3 installer to the devops pipeline
- task: UseDotNet#2
displayName: 'Install .net core 3.0.100'
inputs:
packageType: sdk
version: '3.0.100'
installationPath: $(Agent.ToolsDirectory)/dotnet
The octopus part of my azure-pipelines.yml looks like this:
- task: OctoInstaller#4
inputs:
version: 'latest'
- task: OctopusPush#4
inputs:
OctoConnectedServiceName: 'XXX.octopus.app'
Space: 'Spaces-1'
Package: '$(Build.ArtifactStagingDirectory)/$(Build.DefinitionName).$(Build.BuildNumber).zip'
Replace: 'false'
I have tried every combination of OctoInstaller that I can think of including embedded and explicit version numbers. I keep getting this error message with #4.
Failed to push package. The Octo command line tool is too old to run this task. Please use version 6.10.0 or newer, or downgrade the task to version 3.*.
With OctoInstall#3 I get another error:
Failed to push package. The process '/opt/hostedtoolcache/dotnet/dotnet' failed with exit code 150
Has anyone been able to use dotnet 3 with Octopus deploy? One option
might be to install the octo extension for dotnet but I’m not sure how
you would do that from the azure pipeline. Or to use a Windows build
instead of Ubuntu.
I also noticed an error in the build step.
The specified framework 'Microsoft.NETCore.App', version '2.0.0' was not found.
- The following frameworks were found:
3.0.0 at [/opt/hostedtoolcache/dotnet/shared/Microsoft.NETCore.App]
This means that octopus must be trying to use the dotnet 2 framework.
After looking carefully at the logs, I discovered that OctopusPush was failing because it depends on dotnet 2.0.0. I added in a yml task to install that framework and now it pushes to octopus.
It might be neater to use the dotnet octo tool, as described by TrevorBrooks however I don't know how to install dotnet extensions in the DevOps Pipeline.
Use dotnet octo https://octopus.com/blog/octopus-and-netcore
The blog article explains in detail how to make this work.
For Azure Pipelines follow this article: https://octopus.com/docs/packaging-applications/build-servers/tfs-azure-devops/using-octopus-extension
Keep in mind
The Azure DevOps extension tasks require Octo to be available on the
path when executing on a build agent and must have the .net core 2.0.0
runtime or newer installed. This may not always be possible such as
with the Azure DevOps hosted agents. In order to make this work, all
Octopus tasks will automatically attempt to download and use the
latest version of Octo tools unless they're available on the build
agent as specified above. If you would like to avoid any additional
downloads or to use a specific Octo version then you can by adding the
Octo Installer task to the start of your build definition. No attempt
will be made to download Octo if the capability is detected on your
build agent.

DevOps hosted pipeline fail to build .NET Core 2.2

With the release of .NET Core 2.2 I expected to be able to build such projects in our Microsoft-hosted DevOps (Azure) pipeline. But the restore step fails, saying 2.2 is not supported:
2018-12-11T14:57:49.0856135Z "D:\a\1\s\My.Project\My.Project.csproj" (Restore target) (1) ->
2018-12-11T14:57:49.0857867Z "D:\a\1\s\MyProject.EntityFramework\MyProject.EntityFramework.csproj" (_GenerateRestoreGraphProjectEntry target) (2:3) ->
2018-12-11T14:57:49.0858029Z (_CheckForUnsupportedNETCoreVersion target) ->
2018-12-11T14:57:49.0858191Z C:\Program Files\dotnet\sdk\2.1.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2. [D:\a\1\s\MyProject.EntityFramework\MyProject.EntityFramework.csproj]
2018-12-11T14:57:49.0858287Z
2018-12-11T14:57:49.0858338Z
2018-12-11T14:57:49.0858398Z "D:\a\1\s\My.Project\My.Project.csproj" (Restore target) (1) ->
2018-12-11T14:57:49.0858504Z "D:\a\1\s\My.Project\My.Project.csproj" (_GenerateRestoreGraphProjectEntry target) (1:5) ->
2018-12-11T14:57:49.0858645Z C:\Program Files\dotnet\sdk\2.1.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2. [D:\a\1\s\My.Project\My.Project.csproj]
The project builds fine locally, so I think it is most likely that I'm missing something - especially as I come up with nothing on my internet search for similar errors.
Could it really be it is not supported yet?
OK, so there is a task ".NET Core Installer" that can be added before the Restore task, and by requesting 2.2.100 to be installed first of all the build passes.
This does trick to my project:
steps:
- task: DotNetCoreInstaller#0
displayName: 'Use .NET Core SDK Tool Installer'
inputs:
version: 2.2.100
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
I had the same problem with my pipeline. Here is the solution:
Add to your job (press plus button) in the pipeline task .NET Core SDK Installer. You can search for it in a search box
Make sure to put that task on the top of your job. You can use drag&drop.
Set up version of .Net Core SDK Installer at least the same your version.
You can see all available version by pressing on the "here" word the in the popup
The answer of #bit0001 is correct. Microsoft has a list of supported versions that can be installed using this task. You can find those versions here.
As you can see, 2.1.500 is supported when installing the sdk, 2.1.0 is not, you'll need to use 2.1.300. When installing only the runtime, you can use 2.1.0. Currently, the latest 2.2 version supported is 2.2.100.

How do I build a pre-release package with the .net Core build task

I have a solution that contains a number of csproj's.
In my CI, I want all csproj to build both a pre-release package, with the build number as prerelease string, and a release package with the regular version number.
Later, in a release step, I want to push all pre-release packages automatically, and be able to make a manual release for each release package individually.
My csproj file contains
<VersionPrefix>1.8.0</VersionPrefix>
<VersionSuffix>$(VersionSuffix)</VersionSuffix>
From the CLI, I would build a pre-release version with dotnet pack --version-suffix foo to build version 1.8.0-foo, and use dotnet pack without additional arguments to build version 1.8.0
I'm trying to use the .net Core 2.* build task. I'm seeing automated versioning under pack options/automatic versioning, but those seem to ignore the version prefix in the csproj file.
How do I configure things so that the same csproj can be built in to a pre-release package in one task, and into a release nuget package in another, that differ only in that one has a version suffix set to the build number, and the other without a version suffix?
EDIT:
I tried setting VersionSuffix=bar in additional properties, but this gave me a rather uninformative error:
log:
2018-05-07T10:31:27.1536721Z [command]C:\Windows\system32\chcp.com 65001
2018-05-07T10:31:27.1629285Z Active code page: 65001
2018-05-07T10:31:28.1487070Z [command]"C:\Program Files\dotnet\dotnet.exe"
pack D:\a\1\s\path\to\some.csproj --output D:\a\1\a /p:Configuration=release;$VersionSuffix=bar --verbosity Detailed
2018-05-07T10:31:28.3350467Z Microsoft (R) Build Engine version 15.6.84.34536 for .NET Core
2018-05-07T10:31:28.3351167Z Copyright (C) Microsoft Corporation. All rights reserved.
2018-05-07T10:31:28.3351324Z
2018-05-07T10:31:28.4870038Z ##[error]Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
2018-05-07T10:31:28.4881392Z ##[error]An error ocurred while trying to pack the files.
Just add additional task for pre-release package:
.NET Core task (Automatic package versioning: Off)
.NET Core task (Automatic package versioning: Off; Additional build properties: VersionSuffix=foo)

Resources