How to update Xamarin project to C# 9 without CI build failures
A year has passed since the official announcement of C#9, and finally came the moment when we actually decided to update it on our Xamarin project!
This post is not about C#9 features, but about the upgrade process. To learn more about the features, refer to the official announcement:
Code Update
The first part of the update is to reference C#9 in every project of the solution.
Before starting, make sure you use the latest versions of IDEs, as there was a problem building for C#9 in Rider: https://youtrack.jetbrains.com/issue/RIDER-58915
Then make an update in every .csproj
file:
<PropertyGroup>
<LangVersion>9</LangVersion>
</PropertyGroup>
At this moment, everything should be fine: no warnings appeared, the app can be running right from the IDE without any problems.
CI Update
There is no need to update anything in the build process if your CI is working fine after the upgrade.
If you are building CI for your project, click the link below 👇 to know how to do it using GitHub Actions.
🧙♂️ Mastering CI/CD for Xamarin mobile app using GitHub Actions
Let’s say, you noticed that CI fails to build the updated solution, although it can be built locally with the IDE:
Error CS1617 Invalid option ‘9’ for /langversion. Use ‘/langversion:?’ to list supported values.
The reason why this happened is that Visual Studio for Mac now uses its own MSBuild version to build against the latest .NET, and CI builds with an old MSBuild:
Indeed, even when building the solution locally using Terminal, the error appears:
To fix the build workflow, we need to use MSBuild from VS for Mac on the build machine. Details are entirely related to the tooling you are using. In general, the new build command could look like this:
mono '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/bin/MSBuild/Current/bin/msbuild.dll' <other msbuild parameters>
That’s it.
In addition to the fixed CI, we now use the identical versions of MSBuild locally and on the build machine. The opposite may cause potential errors that will be difficult to debug, as we are developing and testing apps locally and expect them to be built with the same tooling on a remote server.