How I Work on .NET MAUI

This is a description on how I build/contribute to .NET MAUI, it may differ from DEVELOPMENT.md. I thought I would write this down in case it helps someone.

Building

If I'm testing the provisioning of .NET and workloads, I may run:

> rm -r bin/dotnet
> dotnet build src/DotNet/DotNet.csproj -bl

This will provision a .NET SDK and the platform workloads like Android, iOS, etc. in the ./bin/dotnet directory. Such that you can use ./bin/dotnet/dotnet to test things.

If I need a Debug build of MAUI, I normally run:

> dotnet cake --target=dotnet-pack-maui

Sometimes I forgot this and just run dotnet cake not specifying the Cake target at all. This also works, it just runs other extra stuff.

If I need a Release build for things like measuring performance, I do:

> dotnet cake --target=dotnet-pack-maui --configuration=Release

Writing C# Code

I use Visual Studio & VS Code together, but mostly Visual Studio for writing C# and running unit tests. VS Code is better for writing XML or MSBuild targets -- where intellisense doesn't work anyway.

I don't open Microsoft.Maui.sln (or .slnf) in Visual Studio because it just loads way to much stuff and is too slow to open.

I create my own .sln file that is not committed to source control:

# Where my checkout is
C:\src\maui\
# Where I keep random loose .sln files
C:\src\maui\.vs\maui.sln

I slowly add projects to this smaller .sln as needed, currently I have:

This opens more quickly, and I can run the unit tests easily.

Clearing NuGet caches

Before trying to test your local build at the command-line or inside Visual Studio, you may need to run:

rm -r ~\.nuget\packages\*\7.0.100-dev\

This is needed since the following change:

https://github.com/dotnet/maui/commit/2dcc148208c8e805a732f897568baa339304bec4

Testing at the Command-Line

Using ./bin/dotnet/dotnet, I have a Powershell alias for convenience:

Set-Alias maui 'C:\src\maui\bin\dotnet\dotnet.exe'

I put this in my $profile, such as code $profile and then .$profile will reload any changes in the current Powershell session.

With this alias in place, many times I simply go into an empty directory and do:

maui new maui
maui build -t:Run -f net7.0-android

This would build & launch a new app on Android.

Testing inside Visual Studio

Just like my maui alias for the command-line, I have a similar one to launch Visual Studio:

function Dogfood-VS
{
    param(
        [string]$vs = "${env:ProgramFiles}\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\devenv.exe",
        [string]$dotnet = "C:\src\maui\dotnet\",
        [string]$sln = "",
        [bool] $debug = $false
    )

    # Get full path
    if ($sln -ne "")
    {
        $sln=(Get-Item $sln).FullName
    }

    $oldPATH=$env:PATH
    $oldMSBuildDebugEngine=$env:MSBuildDebugEngine
    $oldDOTNET_MULTILEVEL_LOOKUP=$env:DOTNET_MULTILEVEL_LOOKUP
    $oldVSDebugger_ValidateDotnetDebugLibSignatures=$env:VSDebugger_ValidateDotnetDebugLibSignatures
    try {
        # Put our local dotnet.exe on PATH first so Visual Studio knows which one to use
        $env:PATH = ($dotnet + ";" + $env:PATH)
        # Get "full" .binlog in Project System Tools
        if ($debug -eq $true) {
            $env:MSBuildDebugEngine='1'
        }
        $env:DOTNET_MULTILEVEL_LOOKUP='0'
        $env:VSDebugger_ValidateDotnetDebugLibSignatures='0'
        & "$vs" "$sln"
    } finally {
        $env:PATH=$oldPATH
        $env:MSBuildDebugEngine=$oldMSBuildDebugEngine
        $env:DOTNET_MULTILEVEL_LOOKUP=$oldDOTNET_MULTILEVEL_LOOKUP
        $env:VSDebugger_ValidateDotnetDebugLibSignatures=$oldVSDebugger_ValidateDotnetDebugLibSignatures
    }
}

The env vars I'm setting:

%PATH% points to C:\src\maui\bin\dotnet\
%DOTNET_MULTILEVEL_LOOKUP% prevents dotnet for probing and finding a different dotnet. This may already be removed in .NET 8 and not be needed. It is only a problem on Windows.
%MSBuildDebugEngine% tells VS to create .binlog files in the current directory. It is good for getting logs when Project System Tools cannot.
%VSDebugger_ValidateDotnetDebugLibSignatures% allows the VS debugger to use a unsigned build of the .NET SDK.

You could probably trim this down a bit to only set %PATH% -- that is the minimum for this to work.