Azure DevOps Build Xamarin.IOS with IOS 12 as target - xamarin.ios

I have an Application written with Xamarin and a buildpipline on Azure Devops. This builds fine when I target IOS 11.x. However I would like to update to SDK 12 since Apple starts to enforce this starting in march 2019:
SDK Version Issue - This app was built with the iOS 11.4 SDK. Starting
March 2019, all iOS apps submitted to the App Store must be built with
the iOS 12.1 SDK or later, included in Xcode 10.1 or later.
But when I build I always get this error in my Azure Devops pipeline:
MTOUCH : error MT0074: Xamarin.iOS 11.14.0 does not support a deployment target of 12.0 for iOS (the maximum is 11.4). Please select an older deployment target in your project's Info.plist or upgrade to a newer version of Xamarin.iOS.
Based on this article I tried to set the SDK Version with this script:
/bin/bash -c "sudo $AGENT_HOMEDIRECTORY/scripts/select-xamarin-sdk.sh 5_12_0"
Unfortunately it still uses the 11 SDK instead of 12.
Did I choose the wrong Mono Version or is that the wrong approach to select the Xamarin.IOS SDK?
My complete build YAML for the IOS Job:
queue:
name: Hosted macOS
demands:
- xcode
- Xamarin.iOS
steps:
- bash: |
echo "Select Xamarin Version"
/bin/bash -c "sudo $AGENT_HOMEDIRECTORY/scripts/select-xamarin-sdk.sh 5_12_0"
displayName: 'Select Xamarin Version'
- task: InstallAppleCertificate#2
displayName: 'Install an Apple certificate'
inputs:
certSecureFile: '6f1c094d-c147-41e0-9bc6-c9fe9a40b2e6'
certPwd: '$(P12password)'
- task: InstallAppleProvisioningProfile#1
displayName: 'Install an Apple provisioning profile'
inputs:
provProfileSecureFile: 'a883a983-6027-4382-afd4-94b52736323c'
- task: NuGetToolInstaller#0
displayName: 'Use NuGet'
inputs:
versionSpec: 4.x
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Parameters.solution)'
- task: XamariniOS#2
displayName: 'Build Xamarin.iOS '
inputs:
solutionFile: Src/MoneyFox.Ios/MoneyFox.iOS.csproj
configuration: '$(BuildConfiguration)'

You should be able to select the correct version of Mono and Xcode now based on this documentation. In Azure DevOps in both the build and the release pipelines (before the Xamarin.iOS build task and the release task respectively), I added a command line task that runs the following:
echo 'Updating fastlane...'
sudo gem install fastlane
echo 'Selecting Mono version...'
/bin/bash -c "sudo $AGENT_HOMEDIRECTORY/scripts/select-xamarin-sdk.sh 5_16_0"
echo 'Selecting Xcode version...'
/bin/bash -c "echo '##vso[task.setvariable variable=MD_APPLE_SDK_ROOT;]'/Applications/Xcode_10.1.app;sudo xcode-select --switch /Applications/Xcode_10.1.app/Contents/Developer"

In case it helps: the build SDK and the deployment target are different things. I'm building using the 12.1 SDK, but my deployment target, and minimum OS version, are both set to 8.0.

Check 'MinimumOSVersion' key in info.plist.
If it doesn't exist, add it.
<key>MinimumOSVersion</key>
<string>11.0</string>

This looks like a problem with availability of the right version of the Xamarin.iOS library (12.0 or higher) on the DevOps build machine. While it was according to my observations included with recent updates of VS 15.9 (for Windows), or potentially via the Tools for Xamarin extension (still not sure here completely how it gets to a local machine), the VS on the Azure DevOps build machine is 15.8 and comes with default Xamarin.iOS 11.
So the options here are really use your own build machine with or wait for 15.9 to [hopefully] come to the DevOps machines in time.

Related

Chocolatey fails when installing VS2015 toolset

I have a Azure pipeline that builds C++ DLLs, I need to build with different toolsets.
I can build 143 (vs2022), 142 (vs2019) and, 141 (vs2017), but when trying to build the 140 (vs2015) version I cannot install the toolset.
I tried the visualstudio2015professional package.
I tried the visualcppbuildtools (Visual C++ Build Tools 2015 14.0.25420.1)
I tried the microsoft-visual-cpp-build-tools (Microsoft Visual C++ Build Tools 2015 14.0.25420.1)
I'm basing my pipeline on a VS2022 image :
trigger:
- master
pool:
vmImage: 'windows-2022'
steps:
- task: CmdLine#2
displayName: 'Choco install additional packages'
inputs:
script: |
choco install visualstudio2015professional visualstudio2017professional visualstudio2019professional
I am missing something obvious ?
I get errors similar to this :
2022-02-16T18:07:50.2000629Z WARNING: Generic MSI Error. This is a
local environment error, not an issue with a package or the MSI itself
it could mean a pending reboot is necessary prior to install or something else (like the same version is already installed). Please
see MSI log if available. If not, try again adding
'--install-arguments="'/lv
c:\VisualStudio2015Professional_msi_install.log'"'. Then search the
MSI Log for "Return Value 3" and look above that for the error.
2022-02-16T18:07:50.2222631Z ERROR: Running
["C:\Users\VssAdministrator\AppData\Local\Temp\chocolatey\VisualStudio2015Professional\2015.03.03\vs_professional.exe"
/Quiet /NoRestart /Log
C:\Users\VssAdministrator\AppData\Local\Temp\chocolatey\vs.log ] was
not successful. Exit code was '1603'. Exit code indicates the
following: Generic MSI Error. This is a local environment error, not
an issue with a package or the MSI itself - it could mean a pending
reboot is necessary prior to install or something else (like the same
version is already installed). Please see MSI log if available. If
not, try again adding '--install-arguments="'/lv
c:\VisualStudio2015Professional_msi_install.log'"'. Then search the
MSI Log for "Return Value 3" and look above that for the error..

How to run vstest using Linux agent in azure Release pipeline?

Problem statement:
I have specflow tests written in .NetCore and used to run on windows based agents. Now I need to run these tests in linux agent.
I have used build pipeline with windows based agent to build the artifacts. Then in the Release pipeline I have added the vstest Task and Ubuntu agent as below
Agent Pool: Azure Pipelines
Agent Specfication: Ubuntu 20.04
When I run the pipeline the vstest task gave error as below
This task is supported only on Windows agents and cannot be used on other platforms
How to resolve this issue?
There is a work around to achieve this.
Add dotnet test Task and change the command to 'custom' instead of test and custom command as 'vstest'. The configuration looks as below
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet custom'
inputs:
command: custom
projects: '**/Tests.dll'
custom: vstest
arguments: '--logger:trx;logfilename=TEST.xml'
timeoutInMinutes: 120
You can't use vstest on Linux. vstest requires that either Visual Studio is installed or that you have the VS Test Platform installed.
If you want to use vstest you can change the Agent Specification to Windows.

Azure-Pipeline Build resuts in: The current .NET SDK does not support targeting .NET Core 3.1

I have got a Visual Studio 2019 Solution with a .NET Framework Application, with a Azure Pipeline that builds and deploys a web app.
I recently added an Azure Functions Project to my solution. (.net core)
The two projects in the solution do not refrence each other.
On my Local Machine - The solution builds with no problems, and I can run both applications.
However when the Azure Pipeline process tries to build the solution fails with the following error:
Error NETSDK1045: The current .NET SDK does not support targeting .NET
Core 3.1. Either target .NET Core 2.1 or lower, or use a version of
the .NET SDK that supports .NET Core 3.1.
I actually want this Azure Pipeline to ignore the new .net core project, and contiune to build then deploy my web application.
How can I get Azure to build my project in the same way as my local machine?
It looks like that the pipeline is trying to use the wrong .NET Core SDK to compile your projects which are targeting .NET Core 3.1.
You can try adding task Use .NET Core before restore and build task to make sure the .NET Core 3.1 version is used in your pipeline. See below:
- task: UseDotNet#2
inputs:
version: 3.1.302
- task: DotNetCoreCLI#2
inputs:
command: restore
projects: '**/*.csproj'
- task: DotNetCoreCLI#2
inputs:
command: build
projects: '**/*.csproj'
If you used Visual Studio Build task to build your projects, you need to run your pipeline on agent windows-latest which has visual studio 2019 installed. Or you might still encounter this error "The current .NET SDK does not support targeting .NET Core 3.1"
If you want to ignore the new .net core project. You can set the projects attribute of the build task to build a specific project. See below:
- task: DotNetCoreCLI#2
inputs:
command: restore
projects: '**/oldProject.csproj'
- task: DotNetCoreCLI#2
inputs:
command: build
projects: '**/oldProject.csproj'
Visual Studio Build task to build a single project
- task: VSBuild#1
condition: always()
inputs:
solution: '**/oldProject.csproj'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
msbuildArgs: '/t:build'
I had this problem, I had just updated a project from .NET Core 2.2 to .NET Core 3.1 and it stopped building in Azure Devops giving me the error The current .NET SDK does not support targeting .NET Core 3.1 during the Nuget Restore task.
The pipeline was using the Nuget Tool Installer task before the Nuget Restore. The installer was using a version of Nuget that didn't support .NET Core 3.1.
I updated the Nuget Tool Installer to use a newer version and my build ran correctly.

Azure Pipelines is not using the NuGet version specified

This is my original YML file.
trigger:
- master
pool:
vmImage: 'Ubuntu-16.04'
variables:
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#0
displayName: "NuGet use 4.9.3"
inputs:
versionSpec: 4.9.3
- task: DotNetCoreInstaller#0
inputs:
version: '2.2.104'
- task: NuGetCommand#2
displayName: "NuGet Restore"
inputs:
restoreSolution: '**/*.csproj'
- task: DotNetCoreCLI#2
displayName: ".NET build"
inputs:
projects: '**/*.csproj'
arguments: --configuration $(BuildConfiguration) --no-restore
- task: DotNetCoreCLI#2
displayName: ".NET publish package"
inputs:
command: publish
arguments: '--configuration $(BuildConfiguration) --no-restore --output $(Build.ArtifactStagingDirectory)/app/pkg'
This is the output I get for the Nuget Restore step.
[section]Starting: NuGet restore
============================================================================== Task : NuGet Description : Restore, pack, or push NuGet
packages, or run a NuGet command. Supports NuGet.org and authenticated
feeds like Package Management and MyGet. Uses NuGet.exe and works with
.NET Framework apps. For .NET Core and .NET Standard apps, use the
.NET Core task. Version : 2.147.6 Author : Microsoft
Corporation Help : More
Information
============================================================================== Caching tool: NuGet 4.1.0 x64 Found tool in cache: NuGet 4.1.0 x64
Resolved from tool cache: 4.1.0 Using version: 4.1.0 Found tool in
cache: NuGet 4.1.0 x64
How do I disable the use of "tool cache"? It is using 4.1.0 instead of 4.9.3.
UPDATE: As recommended by the comments, I updated my YML file.
trigger:
- master
pool:
vmImage: 'vs2017-win2016'
variables:
buildConfiguration: 'Release'
steps:
- task: DotNetCoreCLI#2
inputs:
command: restore
- task: DotNetCoreCLI#2
displayName: ".NET build"
inputs:
projects: '**/*.csproj'
arguments: --configuration $(BuildConfiguration) --no-restore
- task: DotNetCoreCLI#2
displayName: ".NET publish package"
inputs:
command: publish
arguments: '--configuration $(BuildConfiguration) --no-restore --output $(Build.ArtifactStagingDirectory)/app/pkg'
I still get errors.
It's still doing the same thing.
Starting NuGet restore
Task : NuGet
Description : Restore, pack, or push NuGet
packages, or run a NuGet command. Supports NuGet.org and authenticated
feeds like Package Management and MyGet. Uses NuGet.exe and works with
.NET Framework apps. For .NET Core and .NET Standard apps, use the
.NET Core task. Version : 2.147.6 Author : Microsoft
Corporation Help : More
Information h t t p s ://go.microsoft.com/fwlink/?LinkID=613747
Caching tool: NuGet 4.1.0 x64 Found tool in cache: NuGet 4.1.0 x64
Resolved from tool cache: 4.1.0 Using version: 4.1.0 Found tool in
cache: NuGet 4.1.0 x64 SYSTEMVSSCONNECTION exists true
SYSTEMVSSCONNECTION exists true [command]C:\windows\system32\chcp.com
65001 Active code page: 65001 Detected NuGet version 4.1.0.2450 /
4.1.0 SYSTEMVSSCONNECTION exists true Saving NuGet.config to a temporary config file.
[command]C:\hostedtoolcache\windows\NuGet\4.1.0\x64\nuget.exe sources
Add -NonInteractive -Name NuGetOrg -Source
https://www.nuget.org/api/v2/ -ConfigFile
d:\a\1\Nuget\tempNuGet_57.config Package Source with Name: NuGetOrg
added successfully. Saving NuGet.config to a temporary config file.
Why is it even doing a Nuget Restore when it is no longer in my YML file?
This is working for me
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 4.9.x'
inputs:
versionSpec: 4.9.x
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Pipeline.TriggerDirectory)/Library.sln'
vstsFeed: '[your feed here]'
noCache: true
Log
Tool install
[section]Starting: Use NuGet 4.9.x
=========================================================================
Task : NuGet Tool Installer
Description : Acquires a specific version of NuGet from the internet or the
tools cache and adds it to the PATH. Use this task to change the version of NuGet used in the NuGet tasks.
Version : 0.145.0
Author : Microsoft Corporation
Help : More Information
=========================================================================
You are using a query match on the version string. Behavior changes or breaking changes might occur as NuGet updates to a new version.
Downloading: https://dist.nuget.org/win-x86-commandline/v4.9.3/nuget.exe
Caching tool: NuGet 4.9.3 x64
Using version: 4.9.3
Found tool in cache: NuGet 4.9.3 x64
Using tool path: C:\hostedtoolcache\windows\NuGet\4.9.3\x64
Prepending PATH environment variable with directory: C:\hostedtoolcache\windows\NuGet\4.9.3\x64
[section]Finishing: Use NuGet 4.9.x
Package restore
[section]Starting: NuGet restore
=========================================================================
Task : NuGet
Description : Restore, pack, or push NuGet packages, or run a NuGet command. Supports NuGet.org and authenticated feeds like Package Management and MyGet. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
Version : 2.147.6
Author : Microsoft Corporation
Help : More Information
=========================================================================
SYSTEMVSSCONNECTION exists true
SYSTEMVSSCONNECTION exists true
[command]C:\windows\system32\chcp.com 65001
Active code page: 65001
Detected NuGet version 4.9.3.5777 / 4.9.3+e5150f1e119e456e01c4f1e413213d392eda1c3a
SYSTEMVSSCONNECTION exists true
Saving NuGet.config to a temporary config file.
[command]C:\hostedtoolcache\windows\NuGet\4.9.3\x64\nuget.exe
The tools installer and NuGet tasks are more appropriate for Windows machines. Since you're using an Ubuntu agent, just use the dotnet restore command:
- task: DotNetCoreCLI#2
inputs:
command: restore

VSTS - Xamarin iOS Build - How to choose the mono version to use?

I'm building a Xamarin iOS project on the Hosted macOS Preview queue of VSTS.
The log shows that it uses mono 5.8.0. However, the queue specs show that mono 5.10.0 is installed.
The question is how can to choose the version of mono to use (amongst those installed) to build a xamarin ios project on vsts?
UPDATE
Itried the following after #valdetero's answer
- task: XamariniOS#2
displayName: 'Building iOS'
inputs:
solutionFile: '**/*.sln'
configuration: 'Release'
mdtoolFile: '/Library/Frameworks/Mono.framework/Versions/5.10.1/bin'
However, I got that error:
[error]Xamarin.iOS task failed with error Error: Unable to locate executable file: '/Library/Frameworks/Mono.framework/Versions/5.10.1/bin'.
In your Xamarin.iOS task, open Advanced, check MSBuild, and look at build tool path. Specify an installed version of mono here. I used this for an old project where I can't build it with Mono 5. Here's what I have in the box:
/Library/Frameworks/Mono.framework/Versions/4.8.1/bin
Put that entire path in the box.

Resources