What’s New in .NET MAUI RC2

Yes, another RC in such a short span of two weeks’ time. A more polished version and most importantly Samsung Tizen joins the .NET MAUI bandwagon. And it seems one more RC to follow before the GA release later this month.

In this post, we’re going the see what’s got changed in .NET MAUI RC2 in detail.

• Samsung Tizen added as a target platform to .NET MAUI
• Listing the installed .NET workloads in the command line
• Building the Windows platform target with dotnet CLI command
• Application identifier for Windows and Target platform conditions have been made more convenient

In fact, Tizen .NET enables us to build .NET applications with Xamarin.Forms itself. The Tizen .NET platform is supported by Samsung. Now, continues its journey with Xamarin.Forms evolution of .NET MAUI.

It follows the same .NET 6 workload concept, hence to build and run the application targeting the Tizen platform, one needs to install the optional Tizen workload. Follow the instructions in this link to install the workload.

Note: Since .NET MAUI works on top of .NET 6 and is yet to start its preview release with .NET 7. If you have both .NET 6 and .NET 7 preview releases installed on the same machine, then may face an issue while installing the Tizen workload from within VS IDE and I faced this issue. At first, installed the Visual Studio Tools for Tizen from the Manage Extensions dialog, then followed with the installation of Tizen .NET from the menu item Tools -> Tizen -> Tizen Package Manager. This resulted in all the relevant paths being filled in as mentioned in this screenshot. But when tried to install the optional workload, it didn’t go through.

Update: The Tizen team has shared a link for troubleshooting the errors in workload installation. If that doesn’t work, try the below steps that worked for me.

So after doing some research, found out that, this can be accomplished from the command line from a folder where the context is set to .NET 6 with the help of a global json file.

First, create a global json file with the below command.

dotnet new globaljson --sdk-version 6.0.200 --roll-forward latestMinor

Then open a PowerShell command prompt in Administrator mode in the same folder context and run the CLI command made available here. This completed the optional Tizen workload installation successfully.

And the second new feature of this RC2 release is the listing of the installed workloads in the CLI irrespective of whether it’s acquired via CLI or VS installer.

In the same .NET 6 context (or confirm with dotnet --version command), run the below command to list the installed workloads.

dotnet workload list

Here’s the output of this command from my machine:

Now to build the .NET MAUI app targeting the Tizen platform, open the project file, and uncomment the line as highlighted in the below screenshot. Use Ctrl+K+U shortcut in VS IDE to avoid any errors. For existing projects, this can be added to the project file.

If you’re using VS, then use the Platform Switcher to change the Target to Tizen and then build the app or if you prefer CLI, then use the below command:

dotnet build -f net6.0-tizen

Since the emulator is not yet released by the Tizen team, could not able to see the output of this app. And Tizen-related artifacts are available in the folder Platforms\Tizen and follow the same startup process as described in this article.

Moving on to the next feature, the most important aspect of .NET MAUI is being the Single Project structure, SDK-style project, and Support for .NET CLI. But prior to RC2 apart from the Windows target, all others can be built with the dotnet CLI command whereas building Windows platform required full MSBuild runtime. Even the project file had this condition.

<TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('windows')) and '$(MSBuildRuntimeType)' == 'Full'">$(TargetFrameworks);net6.0-windows10.0.19041</TargetFrameworks>

But now from RC2 onwards, Windows target can also be built using the dotnet CLI and the condition in the project file is also reduced to just OS check.

<TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('windows'))">$(TargetFrameworks);net6.0-windows10.0.19041.0</TargetFrameworks>

The command to build the Windows target is as shown below, very useful for library developers and CI engineers.

dotnet build -f net6.0-windows10.0.19041.0

And last but not least, the project file is now getting revamped such that even the new developers can understand better, and the chance of making a mistake is proactively eliminated.

Apart from the Windows platform, all other targets rely on a Uniform Type Identifier (UTI) based app identifiers like (com.companyname.myapp), but Windows relies on the GUID. To accommodate this in the same project file, another ApplicationId tag with a condition is introduced in Preview 14. But this can lead to errors if the condition is modified and requires an understanding of the project file semantics (hard for new developers onboarding) so this is now replaced with a more meaningful tag ApplicationIdGuid.

Before:

<ApplicationId Condition="$(TargetFramework.Contains('-windows'))">f7bc9297-e84a-4d83-8bf1-bd9742fb212b</ApplicationId>

Now:

<ApplicationIdGuid>2bbb06b3-094a-48dc-9c17-96863ecc4763</ApplicationIdGuid>

The same is the case with platform conditions, prior to RC2, everything was based on the TFMs. But now, this has been updated to be more natural and everyone can get to know about it at first glance itself. A sample is shown below as conveying ios is a lot easier than net6.0-ios.

Before:

<SupportedOSPlatformVersion Condition="'$(TargetFramework)' == 'net6.0-ios'">14.2</SupportedOSPlatformVersion>

Now:

<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">14.2</SupportedOSPlatformVersion>

Happy coding. Stay connected as we continue to learn and share the experiences from this exciting journey of being a .NET developer.