Compiler conflicts for the types in Xamarin.Android.Arch.Work.*

[PureWeen]

Describe your Issue:

xamarin/Xamarin.Forms#9546 (comment)

Steps to Reproduce (with link to sample solution if possible):

App29.zip

[mattleibow]

This might work, well it appears it does.

It removes the Support assembly from the core compile (the csc / roslyn). This way the build will create the assembly, and then leave the migration tasks to clean it all up.

<!-- remove the bad assembly from csc  -->
<Target Name="RemoveOldSupportFromCsc" BeforeTargets="CoreCompile">
  <ItemGroup>
    <__RemovingFromReferencePathWithRefAssemblies Include="%(ReferencePathWithRefAssemblies.Identity)" Condition="'%(Filename)' == 'Xamarin.Android.Arch.Work.Runtime'" />
  </ItemGroup>
  <ItemGroup>
    <ReferencePathWithRefAssemblies Remove="@(__RemovingFromReferencePathWithRefAssemblies)" />
  </ItemGroup>
</Target>

<!-- add it back, just in case -->
<Target Name="AddOldSupportFromCsc" AfterTargets="CoreCompile">
  <ItemGroup>
    <ReferencePathWithRefAssemblies Include="@(__RemovingFromReferencePathWithRefAssemblies)" />
  </ItemGroup>
</Target>

This may seem like a thing we should be adding to the migration, but it could potentially cause more issues that it solves. Potentially.

An example would be if you are using the Xamarin.Android.Support.Emoji package. This has 2 types of namespaces: Support and AndroidX. The AndroidX namespace contains the FlatBufferBuilder type that probably isn't used as much as the EmojiCompat type.

OptionA:
As a result, if we do not put this code into the migration, you won't notice anything. The EmojiCompat will work and then be migrated under the hood. All is good. If you are using the FlatBufferBuilder, then you will have issues, and could potentially add this type of target for your case. And then you will have to update some code to use the AndroidX types instead of the Support types.

Option B:
But, if we were to add this type of target, you will find that ALL the types from the emoji package is gone, including the EmojiCompat. If you were using the FlatBufferBuilder, then you will have to go and change code as in the first option. But, the pain comes in that you will now also have to change code for EmojiCompat as well.

The number of people using FlatBufferBuilder are far fewer than those using EmojiCompat. So this is why we went with option A.

I had a check, and I believe the types that may have this issue are:

• all the types in Xamarin.Android.Support.VersionedParcelable
• AndroidX.Core.Graphics.Drawable.IconCompatParcelizer in Xamarin.Android.Support.Compat
• all the types in Xamarin.Android.Support.RecyclerView.Selection
• AndroidX.Media.AudioAttributesCompatParcelizer and AndroidX.Media.AudioAttributesImplBaseParcelizer in Xamarin.Android.Support.Media.Compat
• the AndroidX.Text.Emoji.FlatBuffer.* types in Xamarin.Android.Support.Emoji
• the AndroidX.Browser.BrowserActions.* in Xamarin.Android.Support.CustomTabs
• the AndroidX.Slice.Builders.* types in Xamarin.Android.Support.Slices.Builders
• all the types in the Xamarin.Android.Support.Slices.* packages
• all the types in the Xamarin.Android.Arch.Work.* packages
• the AndroidX.WebKit.* types in Xamarin.Android.Support.WebKit
• all the types in Xamarin.Android.Support.HeifWriter

At the end of the day, there are a few, but the ones you might hit are the types in Xamarin.Android.Support.Slices and Xamarin.Android.Arch.Work. Maybe the Xamarin.Android.Support.WebKit. But that is mostly it. And, this is only if you are actually writing C# code to use it. It does not affect you if there is some compiled assembly that is using things. Just if you have written C# code using these types.

For those who want to check the list exactly, we have a csv for the mappings. To check, look for the types where the namespace under the Support .NET namespace column starts with AndroidX.

[brendanzagaeski]

This might or might not be useful, but a thought crossed my mind that one way to avoid the C# compilation error might be to use an extern alias.

For assemblies from NuGet packages, this requires a custom <Target> for now.

So I tried:

1. Edit the .csproj file from the App29.zip sample project to add the following lines just before the closing </Project>:

   <Target Name="AddCustomAliases" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
     <ItemGroup>
       <ReferencePath Condition="'%(FileName)' == 'Xamarin.AndroidX.Work.Runtime' AND '%(ReferencePath.NuGetPackageId)' == 'Xamarin.AndroidX.Work.Runtime'">
         <Aliases>AndroidXWorkRuntime</Aliases>
       </ReferencePath>
     </ItemGroup>
   </Target>

2. Remove the ExcludeAssets="compile" attribute from:

   <PackageReference Include="Xamarin.Android.Arch.Work.Runtime" ExcludeAssets="compile">

3. Add the extern alias to the top of MainActivity.cs:

   extern alias AndroidXWorkRuntime;

4. Update using AndroidX.Work:

   using AndroidXWorkRuntime::AndroidX.Work;

5. Build with msbuild -restore -p:AndroidDexTool=d8 in a Visual Studio 2019 version 16.4 environment.

Result: The build completed successfully.

[jpobst]

This seems to document the workarounds pretty good and I don't think we're going to make a code change for this, so I'm gonna close it. It can be reopened if anyone feels different.