Currently, let's say you have a "Hello World" Xamarin.Android application project on Windows.

You might have the following properties in your HelloWorld.csproj:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>True</DebugSymbols>
    <DebugType>full</DebugType>
</PropertyGroup>

NOTE: the latest template puts DebugType=portable here

When built, what will currently happen:

• HelloWorld.dll is compiled
• HelloWorld.dll.mdb is the generated symbol file
• We run a ConvertDebuggingFiles MSBuild task (runs pdb2mdb) that is taking ~50ms for "Hello World". (I have seen it take up to 4 seconds, in cases where Mono.Android.dll.mdb existed, see [build] DebugType=portable across all projects #2215)
• We look for any *.mdb files in _CollectMdbFiles and _CopyMdbFiles targets

As you can see, it is a lot of work to support this file format. Making sure all our of project templates have DebugType=portable is the first step.

What happens in VS for Mac?

The VS for Mac templates are not yet shared with the VS Windows templates, and they are specifying DebugType=full by defaut.

However, Mono is building portable *.pdb files with this setting. ConvertDebuggingFiles and pdb2mdb aren't running at all.

What should we change?

The first thought, is that Xamarin.Android.Common.targets should do this by default:

<DebugType Condition=" '$(DebugType)' = '' OR '$(DebugType)' == 'full' OR '$(DebugType)' = 'pdbonly'>portable</DebugType>

This would make Xamarin.Android projects always use portable *.pdb files by default. DebugType=portable is set by SDK-style NetStandard projects by default. It works for both Debug and Release builds.

We would also remove:

• Anything looking for *.mdb files
• ConvertDebuggingFiles and pdb2mdb

If we encounter a "non-portable" pdb file, it will also be skipped and a new warning emitted.

Benefits

These changes cleanup our MSBuild targets and remove code (reduce technical debt).

It will also improve build times. How much? This is an estimate, but I'm seeing 50-100ms in past SmartHotel360 build logs looking for and copying *.mdb files. I think this time is spent even on builds with no changes. I see 300ms being spent on ConvertDebuggingFiles, but this only happens when assemblies are changing.

Concerns

The main concern here is existing NuGet packages, and what will happen.

• If a *.mdb file is encountered, it will just be ignored
• If a non-portable *.pdb file is encountered we will emit a warning and ignore it

So I think the only thing that someone could lose here is the ability to debug and step into code inside an existing NuGet package.

See: NuGet/Home#6104