Azure Pipelines Xamarin.Forms iOS build fails with error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project - xamarin.forms

We have Xamarin.Forms solution with iOS and UWP projects. We use Azure pipelines to build the iOS project. Until yesterday everything was working fine.
Now the build fails at the NuGet Restore step with the error:
##[error]The nuget command failed with exit code(1) and error(/Users/runner/work/1/s/"MyProjectName.UWP".csproj : error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project.
We can see that the problem occurs when trying to restore NuGet packages for the UWP project on the Mac OS build host.
Image: macOS-11
Workaround will be to exclude it from the solution, but we are using it for testing purposes and this is not a good option for us.

We had the same problem yesterday for our iOS (macos-11) and Android (macos-10.15) Pipelines.
The issue 21180 for mono seems to be the root cause, which is also referenced in a pull request to update the mono version for MacOs virtual environments. Regarding to this workflow test we gave msbuild a chance, and it works.
Solution:
Instead of NuGet restore we use directly MSBuild.
- task: MSBuild#1
inputs:
solution: 'App.sln'
configuration: 'Release'
msbuildArguments: /t:restore
Looking at the log file, MSBuild ignores the UWP project. That is the behavior that NuGet had with the older mono version 6.12.0.125. Ignoring the UWP-Project is no problem, because it can only be build on windows environments.
Project "/Users/runner/work/1/s/App.sln" on node 1 (Restore target(s)).
ValidateSolutionConfiguration:
Building solution configuration "Release|Any CPU".
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/NuGet.targets(315,5): warning : Skipping restore for project '/Users/runner/work/1/s/App/App.UWP/App.UWP.csproj'. The project file may be invalid or missing targets required for restore. [/Users/runner/work/1/s/App.sln]
Some additional information:
The NuGet restore task uses msbuild to find all referenced packages. If that fails, it will use the packages.config file as fallback, the pipeline step will not fail.
Instead we got an error in the build steps for Android & iOS:
error NETSDK1004: Assets file
'/Users/runner/work/1/s/../obj/project.assets.json' not found. Run a
NuGet package restore to generate this file.

Updated Answer
This can be resolved using MSBuild task instead, as the collogues mentioned below.
However, in my case this still lead to the same error. After investigating the pipeline. The root cause has been identified:
Both in MSBuild#1 and XamariniOS#2 tasks
you should target the specific iOS Project and not the solution file, like so:
"
- task: MSBuild#1
inputs:
solution: 'PathToIosProject/myproject.iOS.csproj'
configuration: '$(BuildConfiguration)'
msbuildArguments: /t:restore
" - task: XamariniOS#2
inputs:
solutionFile: PathToIosProject/myproject.iOS.csproj'
configuration: '$(BuildConfiguration)'
packageApp: true
signingIdentity: $(APPLE_CERTIFICATE_SIGNING_IDENTITY)
Old Answer
We have managed to resolve the issue. The root cause of it seems to be an update to the mono framework in the MacOS pipeline build agent.
In order to fix it, we need a script for downloading and installing an older version of the mono framework as a first step of the build pipeline like so:
link to the pipeline tasks photo
This is the code of the bash scrip used in the task:
#!/bin/bash
set -ex
MONO_MACOS_PKG_DOWNLOAD_URL='https://download.mono-project.com/archive/6.12.0/macos-10-universal/MonoFramework-MDK-6.12.0.100.macos10.xamarin.universal.pkg'
mkdir -p /tmp/mono-install
cd /tmp/mono-install
mono --version
wget -q -O ./mono-installer.pkg "$MONO_MACOS_PKG_DOWNLOAD_URL"
sudo installer -pkg ./mono-installer.pkg -target /
mono --version
ls -alh /Library/Frameworks/Mono.framework/Versions/Current

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.

Assets file project.assets.json doesn't have a target for 'net6.0-windows10.0.19041.0/win-x64'

I have a .NET 6 Windows Desktop app that I deploy with MSIX.
I can run and debug it on my own computer, but it fails to build with Azure Pipelines YAML.
I get the error:
C:\Program
Files\dotnet\sdk\6.0.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5):
error NETSDK1047: Assets file 'D:\a\1\s\MyApp\obj\project.assets.json'
doesn't have a target for 'net6.0-windows10.0.19041.0/win-x64'. Ensure
that restore has run and that you have included
'net6.0-windows10.0.19041.0' in the TargetFrameworks for your project.
You may also need to include 'win-x64' in your project's
RuntimeIdentifiers.
App project file:
<TargetFramework>net6.0-windows10.0.19041.0</TargetFramework>
<RuntimeIdentifier>win10-x64</RuntimeIdentifier>
<Platforms>x64</Platforms>
Installer project file:
<TargetPlatformVersion>10.0.19041.0</TargetPlatformVersion>
<TargetPlatformMinVersion>10.0.19041.0</TargetPlatformMinVersion>
<TargetFramework>net6.0-windows10.0.19041.0</TargetFramework>
<RuntimeIdentifier>win10-x64</RuntimeIdentifier>
The pipeline task is VSBuild with Visual Studio 2022 (v. 17)
Nuget tool is version 6.0 installed with NugetToolInstaller task.
Azure Windows agent uses vmImage: 'windows-2022'
The error says:
Ensure that you have included 'net6.0-windows10.0.19041.0' in the
TargetFrameworks for your project. You may also need to include
'win-x64' in your project's RuntimeIdentifiers.
I have added 'net6.0-windows10.0.19041.0' in the TargetFramework for both the app and the installer projects.
If I replace win10-x64 with win-x64 it can build, but I need to use win10-x64 because one of the packages requires it (Microsoft.PowerShell.SDK with System.Management.Automation).
NEW:
After adding /p:RestoreLockedMode=true in the VS Build task, I now get the error:
MyApp.Installer.wapproj : error NU1004: The project MyApp has no
compatible target framework. The packages lock file is inconsistent
with the project dependencies so restore can't be run in locked mode.
Disable the RestoreLockedMode MSBuild property or pass an explicit
--force-evaluate option to run restore to update the lock file.
NEW NEW: I upgraded to .NET 7 but get the same error.
How do I fix the error?

Install & run custom dotnet tool on azure devops release

I'm trying to build a Release pipeline that is triggered by a new version of a published dotnet core tool. The trigger works fine, but I'm unable to install and run the tool in my Tasks.
CURRENTLY:
Running a Command Line Task results in a 401:
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json. [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
The tool package could not be restored.
Tool 'myapp' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
This leads me to believe that I'm missing something here, making it more complicated than it needs to be, or thinking about this the wrong way. The tools in the feed can be installed locally, so I believe it's my release approach.
I'm currently looking into Personal Access Tokens (PAT)
PREVIOUSLY:
If I use the .Net Core task and the custom option:
The logs show a malformed command passed to dotnet.exe:
[command]"C:\Program Files\dotnet\dotnet.exe" "dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
or
[command]"C:\Program Files\dotnet\dotnet.exe" "tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
I've tried varying arguments and I tend to always see the same error message:
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
Your custom dotnet command is quoted and dotnet is repeated : dotnet.exe" "dotnet tool install ..." so the command is misinterpreted.
You can use the Command Line task and set the dotnet command directly :
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
Using the .Net Core task works perfect for us.
Since the dotnet command is quoted, you need to set tool as the command and update into arguments. NuGet credentials can be provided with NuGet Auth task if needed.
Here is my walkaround:
I firstly published my private dotnet tool nupkg file also as an universal package to the same Azure Artifacts feed.
I was able to then use Universal Package task to download the .nupkg file into $(System.DefaultWorkingDirectory)/nupkgs/. This task will handle the authorization to Azure Artifacts feeds.
steps:
- task: UniversalPackages#0
displayName: 'Download mytool.cli.universal'
inputs:
downloadDirectory: '$(System.DefaultWorkingDirectory)/nupkgs/'
vstsFeed: '63d4aa2f-3ae7-4c27-8c18-aa8e3a9ff353'
vstsFeedPackage: '916d9a27-2c07-4071-8631-377f2ac08ed7'
vstsPackageVersion: 0.2.0
I then had the DotNetCoreCLI task to install my nupkg locally in agents.
steps:
- task: DotNetCoreCLI#2
displayName: 'Install mytool as a dotnet tool'
inputs:
command: custom
custom: tool
arguments: 'install --global mytool.CLI --add-source ./nupkgs --version 0.2.0'
You need to add the nuget authenticate task before you try to access the nuget feed

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.

VSTS build: Packages failed to restore - Unable to resolve 'NETStandard.Library (>= 1.6.1)' for '.NETStandard,Version=v2.0'

I'm getting
Unable to resolve 'NETStandard.Library (>= 1.6.1)' for '.NETStandard,Version=v2.0'.
in VSTS build using Hosted2017 build agent after I upgraded my aspnetcore app to netcoreapp2.0 and my libraries to use netstandard2.0.
Works fine locally.
I've edited my build definition to use .net core build task v2.* preview:
here is the build log:
Current agent version: '2.120.2'
Download all required tasks.
Downloading task: DotNetCoreCLI
Starting: Get Sources
Syncing repository: Liero/vyvojari-sk (GitHub)
...details ommited
HEAD is now at e448a25... Upgraded to .NET Core 2.0
Finishing: Get Sources
Starting: Restore
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command. For package commands, supports NuGet.org and authenticated feeds like Package Management and MyGet.
Version : 2.0.5
Author : Microsoft Corporation
Help : [More Information](https://go.microsoft.com/fwlink/?linkid=832194)
==============================================================================
SYSTEMVSSCONNECTION exists true
Downloading: https://dist.nuget.org/win-x86-commandline/v4.0.0/nuget.exe
Caching tool: NuGet 4.0.0 x64
Using version: 4.0.0
Found tool in cache: NuGet 4.0.0 x64
Saving NuGet.config to a temporary config file.
Can\'t find loc string for key: NGCommon_NoSourcesFoundInConfig
NGCommon_NoSourcesFoundInConfig d:\a\1\Nuget\tempNuGet_734.config
"C:\Program Files\dotnet\dotnet.exe" restore d:\a\1\s\src\CommandStack\CommandStack.csproj --configfile d:\a\1\Nuget\tempNuGet_734.config --verbosity Detailed
Restoring packages for d:\a\1\s\src\CommandStack\CommandStack.csproj...
C:\Program Files\dotnet\sdk\1.0.4\NuGet.targets(97,5): error : Unable to resolve 'NETStandard.Library (>= 1.6.1)' for '.NETStandard,Version=v2.0'. [d:\a\1\s\src\CommandStack\CommandStack.csproj]
Generating MSBuild file d:\a\1\s\src\CommandStack\obj\CommandStack.csproj.nuget.g.props.
Generating MSBuild file d:\a\1\s\src\CommandStack\obj\CommandStack.csproj.nuget.g.targets.
Writing lock file to disk. Path: d:\a\1\s\src\CommandStack\obj\project.assets.json
Restore failed in 115.64 ms for d:\a\1\s\src\CommandStack\CommandStack.csproj.
Errors in d:\a\1\s\src\CommandStack\CommandStack.csproj
Unable to resolve 'NETStandard.Library (>= 1.6.1)' for '.NETStandard,Version=v2.0'.
NuGet Config files used:
d:\a\1\Nuget\tempNuGet_734.config
Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
Packages failed to restore
******************************************************************************
Finishing: Restore
******************************************************************************
and here is the source code: https://github.com/Liero/vyvojari-sk/tree/e448a25fb8c481704e9102aaaeb8b84b9aee7b02
Update 18/09/2017
Step 2 is no longer needed. I've left it in the solution though as it may still help some people. Thanks, #Liero for point this out.
Original Answer
I've just experienced this problem too and solved it by doing three things:
Use the .NET Core SDK(! - not runtime!) version 2.0.0:
Use the latest NuGet feed (4.3.0):
Restore your packages:
Update
It's worth mentioning here that you should specify where you get your NuGet packages from. Most applications will probably just use the NuGet.org feed, as per the screenshot (see small checkbox), but you may have your custom feeds specified in a NuGet.config file. In that case, tick 'Feeds in my NuGet.config' and then specify the path to that file.
To illustrate the order, this is my working queue:
I hope this helps you and anyone else who has come up against this problem. If you have any questions, let me know. :)
You should select Feed(s) I select here for Feeds to use option. If you leave Use packages from this VSTS/TFS feed empty, packages will be downloaded from https://dist.nuget.org/.
Else, if you want to use Feeds in my NuGet.config as Feeds to use, you should specify the path for your NuGet.config file.
I have received a similar error after generating a project using dotnet new angular which created a project relying on netcoreapp2.0. Inspection of project properties revealed that version 2.0 was not properly recognized (did not appear in the installed framework list).
Solution was to update Visual Studio 2017, as the minimum version required to support netcoreapp2.0 projects seems to be 15.3.1.
What worked for me was installing .NET Core SDK 2.0 and making the following changes:
in .csproj:
change
<TargetFramework>netcoreapp1.1.0</TargetFramework>
to
<TargetFramework>netcoreapp2.0</TargetFramework>
and in global.json:
"sdk": { "version": "1.1.0" }
to
"sdk": { "version": "2.0.0" }
I didn't know how to use Chris Paton' solution
Updating the Visual Studio 2017 to latest 15.4.1 version resolved the problem for me.

Resources