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

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.

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..

Issue with building a .netcore3.1 proj within Azure pipeline. Failure only occurs when this proj references another proj (.net framework 4.7.2)

Basically, I have a .netcore 3.1 proj (an exe) that runs flawlessly locally, both with and without a reference to another class library proj (.net framework 4.7.2). However, when I try to get the .netcore3.1 proj to build in Azure it only works when there is no reference to the class library. If there is a reference to the .net framework 4.7.2 class library, the build fails.
Below is the error within the publish portion of the pipeline. This is what comes up when the related code and reference to the class library are being used.
##[debug]Exit code 1 received from tool 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'
##[debug]STDIO streams have closed for tool 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'
##[error]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[debug]Processed: ##vso[task.issue type=error;]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[warning].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
##[debug]Processed: ##vso[task.issue type=warning;].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://learn.microsoft.com/en-us/dotnet/core/tools/ and https://learn.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[debug]task result: Failed
##[error]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
##[debug]Processed: ##vso[task.issue type=error;]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
##[debug]Processed: ##vso[task.complete result=Failed;]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
Finishing: dotnet publish dotnetcore
I find it weird how locally it runs fine, but on Azure only works without the project reference. Any ideas?
To avoid compatibility issues you should use for .NET Core 3.1 -> .NET Standard 2.1, because .NET Framework also implements .NET Standard, it is possible in some cases to include .NET Framework libraries in .NET Core projects but it is not a good practice.
If your app runs locally, the error can be because the dotnet sdk version that you are using locally is different that the one in the azure agent (from the error it is .NET 5). You can check by running this command in you local: $ dotnet --version
To set an specific version of the dotnet sdk for your project you can execute this command in the root folder of your solution file $ dotnet new globaljson, it will generate a global.json file in which you can set the dotnet sdk version you have in your local.
Other option is set the dotnet version in the agent with Use .NET Core YAML task, and after that run the build.
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: '3.1.401'
If you want to know the included software in the Azure pipeline VMs take a look at this link: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#software

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 Builds is adding an extra folder (win-x64) causing build to break

Given:
Visual Studio 2019 Web API .Net Core 3.1
Wix Toolset 3.1.1 (latest)
Wix Toolset Extension for Visual Studio 2019
Windows 2016 Azure DevOps 2019
All I'm trying to do is use Wix Toolset to create an .msi file for a very simple WebAPI project.
The build works perfectly locally of course, but when it runs in Azure Builds I get following error because an extra folder is getting added (win-x64)
Here's a snippet of build script in Azure Pipelines:
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:PublishProfile=FolderProfile'
configuration: '$(buildConfiguration)'
ication1\bin\Release\netcoreapp3.1\win-x64\publish\WebApplication1.exe'
Link:
C:\Program Files (x86)\WiX Toolset v3.11\bin\Light.exe -out C:\agent2\_work\4\s\SetupProject1\bin\Release\SetupProject1.msi -pdbout C:\agent2\_work\4\s\SetupProject1\bin\Release\SetupProject1.wixpdb -cultures:null -contentsfile obj\Release\SetupProject1.wixproj.BindContentsFileListnull.txt -outputsfile obj\Release\SetupProject1.wixproj.BindOutputsFileListnull.txt -builtoutputsfile obj\Release\SetupProject1.wixproj.BindBuiltOutputsFileListnull.txt -wixprojectfile C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj obj\Release\Product.wixobj
Windows Installer XML Toolset Linker version 3.11.2.4516
Copyright (c) .NET Foundation and contributors. All rights reserved.
C:\agent2\_work\4\s\SetupProject1\Product.wxs(28): error LGHT0103: The system cannot find the file 'C:\agent2\_work\4\s\WebApplication1\bin\Release\netcoreapp3.1\win-x64\publish\WebApplication1.exe'. [C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj]
##[error]SetupProject1\Product.wxs(28,0): Error LGHT0103: The system cannot find the file 'C:\agent2\_work\4\s\WebApplication1\bin\Release\netcoreapp3.1\win-x64\publish\WebApplication1.exe'.
C:\agent2\_work\4\s\SetupProject1\Product.wxs(31): error LGHT0103: The system cannot find the file 'C:\agent2\_work\4\s\WebApplication1\bin\Release\netcoreapp3.1\win-x64\publish\appsettings.json'. [C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj]
##[error]SetupProject1\Product.wxs(31,0): Error LGHT0103: The system cannot find the file 'C:\agent2\_work\4\s\WebApplication1\bin\Release\netcoreapp3.1\win-x64\publish\appsettings.json'.
Done Building Project "C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj" (default targets) -- FAILED.
Done Building Project "C:\agent2\_work\4\s\Solution1.sln" (default targets) -- FAILED.
Build FAILED.

Azure DevOps Build Xamarin.IOS with IOS 12 as target

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.

Resources