Xamarin.iOS C# 9 - Invalid option '9' for /langversion - MacOS Hosted Agent #14171
Comments
github-actions
bot
added
Area: ABTT
|
Just as a note a possible workaround: |
|
Thanks to Twitter and after fighting with some other bugs like: xamarin/Essentials#1589 I got it working with a workaround: I created a bash script build-ios.sh And then changed my pipeline yaml: |
|
Any updates about this issue? We are trying to setup ou CI/CD process using Azure DevOps for our Xamarin.Forms application (Android & iOS), but we run into the same error when trying to build both Android and iOS, since we are using C# 9 in all projects of our solution. We have also tried another option, which was to call directly
Any ideas on how long its going to take to update the xamarin related tasks to build projects using C# 9 ? |
|
Any updates? Thanks! |
|
With the workaround mentioned above I'm able to build Android and iOS Xamarin Forms apps with C# 9. Thats not nice or perfect but at least its working. |
|
Hi everyone, this seems to be external issue since Xamarin.iOS pipeline task users tools already installed on agent environment. |
|
@anatolybolshakov this is a known issue. By default, msbuild from mono is used, and it doesn't support C#9 yet, but the msbuild from VS4Mac does, so the workaround is to use msbuild from VS4Mac (more details here microsoft/appcenter#86 (comment)) |
|
@AlenaSviridenko thanks! |
|
I sorted out this issue using my own msbuild script that uses visual studio msbuild. I used this msbuild script for Build path tool property of the Xamarin.iOS task. You should add visualstudio to demands list of your agent.
So I am able to use other tasks utilities. |
@gokhancelik What kind of file did you create? If I create a msbuild.bat or msbuild.sh file it doesn't work |
I am not an active MACOS user so I didn't know the exact method to create an executable file. I remember that I copied from the original msbuild file under Visual Studio application folder and I changed its content as I mentioned below post. |
Finally, this worked for me. |
|
I finally could publish an ipa file content file build-ios.sh#!/bin/bash mono /Applications/Visual\ Studio.app/Contents/Resources/lib/monodevelop/bin/MSBuild/Current/bin/MSBuild.dll /t:Build "$1" /p:Configuration="$2" /p:Platform="$3" /p:buildForSimulator=false /p:BuildIpa=true /p:IpaPackageDir="$4" /p:Codesignkey="$5" /p:CodesignProvision="$6" /p:ArchiveOnBuild=true Content Azure BuildPipelinetrigger:
pool: variables:
steps:
|
|
I'm going to ask here before opening a new ticket, because I don't know whether this is related or not, but does anyone have any idea as to why both the XamariniOS@2 pipeline task, and the bash script published here, keep trying to compile my app with c# 8? All the csproj files in the solution have lang version 9 specified in them, in all their built configurations: but, no matter what I do, I always get this kind of errors when the app is being compiled: I mean, I don't even get an error message saying that c#9 is not supported, the agent just ignores the lang version defined in the project and tries to compile it using c# 8 :( And, of course, the task that compiles the android version of the app, using the same vm-image, does it without any problems (and compiling the iOS version locally works as well). |
|
For C# 10 with VS for Mac 17 on agent macOS-12, I used a command line build task with: |
|
I have got this issue recently when i tried to change the lang version to C# 8. I am using
Have also tried this bash script instead of using Xamarin.iOS@2 task but that also didn't work. I am getting below error message with this bash script. So it was unable to find the MSBuild location is it because the agent doesn't have Visual Studio installed in it? Have tried referencing mono from the location as well using this Could anyone point me to the right direction should i open a ticket for this ? |
|
@FahadSHK I had another bug with the Android Task where someone at MS involved with Xamarin compilation mentioned that he didn't know who was maintaining the Xamarin.iOS and Xamarin.Android tasks (very reassuring), and recommended just running the msbuild task directly. I did that, as @breyed mentions in the comment previous to yours, and that solved the C# version error (still no idea why the Xamarin.iOS task insists in using an old C# version to compile). As using the MSBuild task is not obvious unless you have an example, this is what replaced the Xamarin.iOS task in our case: |
|
@salgiza Thanks for the reply, I have tried your code but i guess this time i ran into a different problem and when i see the error message it just says that looking closely at the message i found out that my code signing key value has a whitespace in the text and i think the msbuild argument is considering the value after the space as a property, i have spend some time trying to escape that whitespace character but i didn't find any proper solution for that. how can we escape a whitespace character in a property value? |
|
@FahadSHK In my case I still use the InstallAppleProvisioningProfile and InstallAppleCertificate tasks, which download the provision and p12 files from DevOps Library/Secure Files, and automatically assign the variables that you saw in my example: "$(APPLE_PROV_PROFILE_UUID)" and "$(APPLE_CERTIFICATE_SIGNING_IDENTITY)", and I haven't had any problems. That being said, I also uploaded both files without whitespaces in them... 😆 |
Question, Bug, or Feature?
Type: Question
Enter Task Name: XamariniOS
Environment
Server - Azure Pipelines
If using TFS on-premises, provide the version:
If using Azure Pipelines, provide the account name, team project name, build definition name/build number:
Agent - Hosted or Private:
Issue Description
Build fails with error: "CSC : error CS1617: Invalid option '9' for /langversion. Use '/langversion:?' to list supported values. [/Users/runner/work/1/s/Common.DependenciesService/Common.DependenciesService.csproj]"
Project itself builds fine with Android (build on Windows-agent) and builds fine locally at my development machines Windows and MacOS.
Pipeline
Error logs
Click to expand!
The text was updated successfully, but these errors were encountered: