Skip to content

Conversation

@jonathanpeppers
Copy link
Member

@jonathanpeppers jonathanpeppers commented Jan 25, 2021

Context: https://github.com/xamarin/Xamarin.Legacy.Sdk

This uses Xamarin.Legacy.Sdk to multi-target.

For this to work:

  • You have to use dotnet build to build any Xamarin.Legacy.Sdk
    projects. Windows can use MSBuild.exe from Visual Studio 16.9
    Preview 4 as well.

The CI build will also have to install:

  • .NET 6.0.100-preview.1.21103.13
  • Microsoft.NET.Android.Workload 11.0.200.50
  • Xamarin.Android 11.2.99.85

Other notes:

  • Class libraries had application properties set like
    $(EnableProguard), $(AndroidEnableMultiDex),
    $(AndroidDexTool), $(AndroidLinkTool), etc.

jonathanpeppers added a commit to jonathanpeppers/XamarinComponents that referenced this pull request Jan 25, 2021
Context: dotnet/android-libraries#247
Context: https://github.com/xamarin/Xamarin.Legacy.Sdk

I'm testing out if we can multi-target the AndroidX libraries for `MonoAndroid90;net6.0-android`.

Unfortunately the build fails because:

1. The `UseDotNet@2` yaml task can't install .NET
   6.0.100-alpha.1.21064.27. We have to use the `dotnet-install`
   script to install it ourselves.

2. `dotnet tool` commands won't work, if there is a `global.json` file
   targeting `6.0.100-alpha.1.21064.27`.

I think for now, we should make it so callers can set `dotnet: ''` and
skip many of these steps. Callers can also leave the `tools: []`
parameter blank.

If a build needs to install .NET 6 and other .NET global tools, I
think it will be able to be done in `preBuildSteps` after these
changes.
jonathanpeppers added a commit to xamarin/XamarinComponents that referenced this pull request Jan 25, 2021
Context: dotnet/android-libraries#247
Context: https://github.com/xamarin/Xamarin.Legacy.Sdk

I'm testing out if we can multi-target the AndroidX libraries for `MonoAndroid90;net6.0-android`.

Unfortunately the build fails because:

1. The `UseDotNet@2` yaml task can't install .NET
   6.0.100-alpha.1.21064.27. We have to use the `dotnet-install`
   script to install it ourselves.

2. `dotnet tool` commands won't work, if there is a `global.json` file
   targeting `6.0.100-alpha.1.21064.27`.

I think for now, we should make it so callers can set `dotnet: ''` and
skip many of these steps. Callers can also leave the `tools: []`
parameter blank.

If a build needs to install .NET 6 and other .NET global tools, I
think it will be able to be done in `preBuildSteps` after these
changes.
@dotnet dotnet deleted a comment from azure-pipelines bot Jan 26, 2021
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this pull request Jan 26, 2021
…r apps

Context: dotnet/android-libraries#247

When porting AndroidX to .NET 6, I noticed something odd... I was
getting `.aar` files in the build output that appeared to contain the
contents of `android-support-multidex.jar`.

Then I noticed:

https://github.com/xamarin/AndroidX/blob/16b02ae51980f7bab7be395d44f9998eea9bf32f/source/AndroidXProject.cshtml#L18

The AndroidX binding projects are setting `$(AndroidEnableMultiDex)`?

This is surely not intentional to be set in a class library, but this
causes `_AddMultiDexDependencyJars` to run:

    <Target Name="_AddMultiDexDependencyJars">
      <!-- ... -->
      <ItemGroup Condition=" '$(AndroidEnableMultiDex)' == 'True' AND '$(AndroidMultiDexSupportJar)' == '' ">
        <AndroidJavaLibrary Include="$(MonoAndroidToolsDirectory)\android-support-multidex.jar" />
      </ItemGroup>
    </Target>

If this was added to `@(AndroidJavaLibrary)`, then the `<CreateAar/>`
MSBuild task would happily package it in a .NET 6 class library!

I think the solution here is that the `_AddMultiDexDependencyJars`
MSBuild target shouldn't actually run unless `$(AndroidApplication)`
is `true`.

I added updated an existing test for this scenario.
jonathanpeppers added a commit to jonathanpeppers/XamarinComponents that referenced this pull request Jan 26, 2021
Context: dotnet/android-libraries#247

To improve upon the changes in abda726, we could add a new
`initSteps` to install .NET 6.

Previously, if we could only install .NET 6 during `preBuildSteps`,
then the `dotnet tool` commands would fail:

    - pwsh: |
        dotnet tool install -g api-tools --version ${{ parameters.apiTools }}
    ...
    displayName: 'Install required .NET Core global tools'

Because .NET 6 is defined in `global.json`, you would get an error
saying there was no .NET 6 installed.

If we add a new `initSteps`, we could do something like:

    initSteps:
      - pwsh: |
          $ProgressPreference = 'SilentlyContinue'
          Invoke-WebRequest -Uri "https://dot.net/v1/dotnet-install.ps1" -OutFile dotnet-install.ps1
          & .\dotnet-install.ps1 -Version $(DotNet6Version) -InstallDir "$env:ProgramFiles\dotnet\" -Verbose
    tools:
      - 'xamarin.androidbinderator.tool': '0.4.2'
      - 'xamarin.androidx.migration.tool': '1.0.7.1'

Then the `dotnet tool` commands will succeed.
jonathanpeppers added a commit to xamarin/XamarinComponents that referenced this pull request Jan 27, 2021
Context: dotnet/android-libraries#247

To improve upon the changes in abda726, we could add a new
`initSteps` to install .NET 6.

Previously, if we could only install .NET 6 during `preBuildSteps`,
then the `dotnet tool` commands would fail:

    - pwsh: |
        dotnet tool install -g api-tools --version ${{ parameters.apiTools }}
    ...
    displayName: 'Install required .NET Core global tools'

Because .NET 6 is defined in `global.json`, you would get an error
saying there was no .NET 6 installed.

If we add a new `initSteps`, we could do something like:

    initSteps:
      - pwsh: |
          $ProgressPreference = 'SilentlyContinue'
          Invoke-WebRequest -Uri "https://dot.net/v1/dotnet-install.ps1" -OutFile dotnet-install.ps1
          & .\dotnet-install.ps1 -Version $(DotNet6Version) -InstallDir "$env:ProgramFiles\dotnet\" -Verbose
    tools:
      - 'xamarin.androidbinderator.tool': '0.4.2'
      - 'xamarin.androidx.migration.tool': '1.0.7.1'

Then the `dotnet tool` commands will succeed.
jonathanpeppers added a commit to dotnet/android that referenced this pull request Jan 27, 2021
…r apps (#5548)

Context: dotnet/android-libraries#247

When porting AndroidX to .NET 6, I noticed something odd... I was
getting `.aar` files in the build output that appeared to contain the
contents of `android-support-multidex.jar`.

Then I noticed:

https://github.com/xamarin/AndroidX/blob/16b02ae51980f7bab7be395d44f9998eea9bf32f/source/AndroidXProject.cshtml#L18

The AndroidX binding projects are setting `$(AndroidEnableMultiDex)`?

This is surely not intentional to be set in a class library, but this
causes `_AddMultiDexDependencyJars` to run:

    <Target Name="_AddMultiDexDependencyJars">
      <!-- ... -->
      <ItemGroup Condition=" '$(AndroidEnableMultiDex)' == 'True' AND '$(AndroidMultiDexSupportJar)' == '' ">
        <AndroidJavaLibrary Include="$(MonoAndroidToolsDirectory)\android-support-multidex.jar" />
      </ItemGroup>
    </Target>

If this was added to `@(AndroidJavaLibrary)`, then the `<CreateAar/>`
MSBuild task would happily package it in a .NET 6 class library!

I think the solution here is that the `_AddMultiDexDependencyJars`
MSBuild target shouldn't actually run unless `$(AndroidApplication)`
is `true`.

I added updated an existing test for this scenario.
Copy link
Contributor

@moljac moljac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@moljac moljac added the do-not-merge PR is still in progress and is not ready to be merged label Feb 9, 2021
@moljac
Copy link
Contributor

moljac commented Feb 9, 2021

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Context: https://github.com/xamarin/Xamarin.Legacy.Sdk

This uses Xamarin.Legacy.Sdk to multi-target.

For this to work:

* You have to use `dotnet build` to build any `Xamarin.Legacy.Sdk`
  projects. Windows can use `MSBuild.exe` from Visual Studio 16.9
  Preview 4 as well.

The CI build will also have to install:

* .NET 6.0.100-preview.1.21103.13
* Microsoft.NET.Android.Workload 11.0.200.50
* Xamarin.Android 11.2.99.85

Other notes:

* Class libraries had application properties set like
  `$(EnableProguard)`, `$(AndroidEnableMultiDex)`,
  `$(AndroidDexTool)`, `$(AndroidLinkTool)`, etc.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this pull request Feb 23, 2021
Context: https://github.com/dotnet/designs/blob/38bffe6c03a149c80f1c3b22787f33c794e71c76/accepted/2021/net6.0-tfms/net6.0-tfms.md

We don't have a complete implementation for .NET 6 & NuGet yet, so for
for things to work *at all* we have `Microsoft.Android.Sdk.NuGet.targets`
that contains workarounds that enable:

* Given some NuGet package, `Foo.nupkg`
* Try `lib/net6.0-android/Foo.dll`
* Try `lib/monoandroid10.0/Foo.dll`, other `$(TFV)` etc.

We can now test the above scenario with AndroidX NuGet packages:

* dotnet/android-libraries#247
* https://pkgs.dev.azure.com/azure-public/vside/_packaging/xamarin-impl/nuget/v3/index.json
* `<PackageReference Include="Xamarin.AndroidX.AppCompat" Version = "1.2.0.7-net6preview01" />`

Unfortunately, consuming `Xamarin.AndroidX.AppCompat` results in our
build using `lib/monoandroid90/Xamarin.AndroidX.AppCompat.dll` over
the .NET 6 one!

I was able to reproduce this failure in the `XASdkTests.DotNetBuild()`
test, as any `Release` build will fail during linking when using
`MonoAndroid` assemblies without `KnownPackages.AddDotNetCompatPackages()`.

To solve the problem, we need to list `net6.0-android30.0` in
`$(PackageTargetFallback)`. Now .NET 6 packages are preferred over
`MonoAndroid` ones. Lastly I added `MonoAndroid11.0`, because it was
missing.

Eventually I hope to delete `Microsoft.Android.Sdk.NuGet.targets`
completely when the NuGet implementation of TFMs in .NET 6 is
complete.
jonathanpeppers added a commit to dotnet/android that referenced this pull request Feb 24, 2021
Context: https://github.com/dotnet/designs/blob/38bffe6c03a149c80f1c3b22787f33c794e71c76/accepted/2021/net6.0-tfms/net6.0-tfms.md

We don't have a complete implementation for .NET 6 & NuGet yet, so for
for things to work *at all* we have `Microsoft.Android.Sdk.NuGet.targets`
that contains workarounds that enable:

* Given some NuGet package, `Foo.nupkg`
* Try `lib/net6.0-android/Foo.dll`
* Try `lib/monoandroid10.0/Foo.dll`, other `$(TFV)` etc.

We can now test the above scenario with AndroidX NuGet packages:

* dotnet/android-libraries#247
* https://pkgs.dev.azure.com/azure-public/vside/_packaging/xamarin-impl/nuget/v3/index.json
* `<PackageReference Include="Xamarin.AndroidX.AppCompat" Version = "1.2.0.7-net6preview01" />`

Unfortunately, consuming `Xamarin.AndroidX.AppCompat` results in our
build using `lib/monoandroid90/Xamarin.AndroidX.AppCompat.dll` over
the .NET 6 one!

I was able to reproduce this failure in the `XASdkTests.DotNetBuild()`
test, as any `Release` build will fail during linking when using
`MonoAndroid` assemblies without `KnownPackages.AddDotNetCompatPackages()`.

To solve the problem, we need to list `net6.0-android30.0` in
`$(PackageTargetFallback)`. Now .NET 6 packages are preferred over
`MonoAndroid` ones. Lastly I added `MonoAndroid11.0`, because it was
missing.

Eventually I hope to delete `Microsoft.Android.Sdk.NuGet.targets`
completely when the NuGet implementation of TFMs in .NET 6 is
complete.
moljac and others added 8 commits March 2, 2021 11:08
This PR is producing:

    Xamarin.AndroidX.AppCompat.Resources.1.1.0.1.nupkg

So it failed to upload to the NuGet feed.
This PR is producing:

    Xamarin.AndroidX.Migration.1.0.8.nupkg
    Xamarin.AndroidX.Migration.Tool.1.0.8.nupkg

So it failed to upload to the NuGet feed.
jonathanpeppers added a commit to dotnet/maui-samples that referenced this pull request Apr 22, 2021
I updated our AndroidX packages via:

dotnet/android-libraries#247

The current build is based on the .NET 6 Preview 3 bits.
jonathanpeppers added a commit to jonathanpeppers/maui that referenced this pull request Apr 22, 2021
We have new AndroidX packages produced from:

dotnet/android-libraries#247

After updating I ran into:

    C:\src\maui\src\Compatibility\Core\src\Android\CollectionView\SelectableViewHolder.cs(44,25):
        error CS0618: 'RecyclerView.ViewHolder.AdapterPosition' is obsolete: 'deprecated' [C:\src\maui\src\Compatibility\Core\src\Compatibility-net6.csproj]
    C:\src\maui\src\Compatibility\Core\src\Android\CollectionView\SelectableItemsViewAdapter.cs(70,9):
        error CS0618: 'RecyclerView.ViewHolder.AdapterPosition' is obsolete: 'deprecated' [C:\src\maui\src\Compatibility\Core\src\Compatibility-net6.csproj]
        0 Warning(s)
        2 Error(s)

`AdapterPosition` is indeed obsolete:

https://stackoverflow.com/a/63148812

It appears we can use `BindingAdapterPosition`, because the deprecated
code is basically:

    @deprecated
    public final int getAdapterPosition() {
        return getBindingAdapterPosition();
    }
jonathanpeppers added a commit to dotnet/maui-samples that referenced this pull request Apr 22, 2021
Latest AndroidX packages coming from:

dotnet/android-libraries#247

These AndroidX packages are based on the .NET 6 Preview 3 bits.
Redth pushed a commit to dotnet/maui that referenced this pull request Apr 23, 2021
We have new AndroidX packages produced from:

dotnet/android-libraries#247

After updating I ran into:

    C:\src\maui\src\Compatibility\Core\src\Android\CollectionView\SelectableViewHolder.cs(44,25):
        error CS0618: 'RecyclerView.ViewHolder.AdapterPosition' is obsolete: 'deprecated' [C:\src\maui\src\Compatibility\Core\src\Compatibility-net6.csproj]
    C:\src\maui\src\Compatibility\Core\src\Android\CollectionView\SelectableItemsViewAdapter.cs(70,9):
        error CS0618: 'RecyclerView.ViewHolder.AdapterPosition' is obsolete: 'deprecated' [C:\src\maui\src\Compatibility\Core\src\Compatibility-net6.csproj]
        0 Warning(s)
        2 Error(s)

`AdapterPosition` is indeed obsolete:

https://stackoverflow.com/a/63148812

It appears we can use `BindingAdapterPosition`, because the deprecated
code is basically:

    @deprecated
    public final int getAdapterPosition() {
        return getBindingAdapterPosition();
    }
@jonathanpeppers
Copy link
Member Author

I think we can close this now, we have #340 merged.

daniel1029-marker added a commit to daniel1029-marker/maui-samples that referenced this pull request Aug 24, 2025
Latest AndroidX packages coming from:

dotnet/android-libraries#247

These AndroidX packages are based on the .NET 6 Preview 3 bits.
kenneth-charriez added a commit to kenneth-charriez/maui-samples that referenced this pull request Aug 25, 2025
Latest AndroidX packages coming from:

dotnet/android-libraries#247

These AndroidX packages are based on the .NET 6 Preview 3 bits.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do-not-merge PR is still in progress and is not ready to be merged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants