Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

.aar file missing from NuGet package for .net6-android binding #7040

Closed
VincentUhlmann opened this issue May 26, 2022 · 6 comments · Fixed by #7045
Closed

.aar file missing from NuGet package for .net6-android binding #7040

VincentUhlmann opened this issue May 26, 2022 · 6 comments · Fixed by #7045
Assignees
@jpobst
Labels
needs-triage Issues that need to be assigned.

Comments

@VincentUhlmann
Copy link

Android application type

Android for .NET (net6.0-android, etc.)

Affected platform version

.NET6-Android

Description

Hey, I am currently facing a problem with a .net6-android binding project. Generally the binding works as long as I add the binding project as reference to e.g. a MAUI app. However, as soon as I make a NuGet package from the binding and use it, I get errors like "JAVAC0000 error: package com.foo.foo does not exist". I have now spent several hours trying to solve the problem, and for example analyzed the NuGet packages with dotPeek. I am now at the point where I have determined that the .aar file to bind does not exist in the NuGet packet. If I compare .net6-android NuGet package with e.g. MonoAndroid, I see that under .net6 no resources folder exists. If I have recognized it correctly, the .aar file should be included in the DLL. I have tried all possible things to solve the error by changing the .csproj of the binding project. I have also taken into account the information that is available here, e.g. "https://github.com/xamarin/xamarin-android/blob/main/Documentation/guides/OneDotNet.md". I can't pinpoint the problem, but I hope someone has an idea how to solve it.

Steps to Reproduce

  1. Create a .net6 android binding project.
  2. Bind an .aar file
  3. Create a NuGet package from the binding project
  4. Try to consume the NuGet package

Did you find any workaround?

No response

Relevant log output

No response
@VincentUhlmann VincentUhlmann added the needs-triage Issues that need to be assigned. label May 26, 2022
@jpobst
Copy link
Contributor

jpobst commented May 26, 2022

In .NET 6 projects, the .aar/.jar is no longer included inside the .dll. You will need to ensure that the file is placed in the NuGet in the same directory as the .dll.

More information is available here:
https://github.com/xamarin/xamarin-android/blob/main/Documentation/guides/OneDotNetEmbeddedResources.md

@jpobst
Copy link
Contributor

jpobst commented May 26, 2022 •
edited

@jonathanpeppers If I create a new binding library and Pack it from the default template with window-extensions-1.0.0-alpha01.aar, I get this:

image

If I use okio-2.10.0.jar, I get this:

image

Contents of AndroidBinding2.aar:

image

Is this the expected result?

@jonathanpeppers
Copy link
Member

Yeah, something seems wrong here, I'll test.

jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue May 27, 2022
@jonathanpeppers
[One .NET] pack AndroidLibrary .aar files in .nupkg
4fa68fb 
Fixes: xamarin#7040

It appears we were missing a test case of:

1. `dotnet new androidlib`

2. Add an `.aar` file

3. `dotnet pack`

4. Assert that `lib\net6.0-android31.0\MyAndroidLibrary.aar` exists in
   the `.nupkg` output

We instead end up with "weird" output in the `.nupkg` like:

    lib\net6.0-android31.0\MyDotNetAssembly.dll
    lib\net6.0-android31.0\MyDotNetAssembly.xml
    lib\net6.0-android31.0\MyDotNetAssembly.aar
    content\MyAndroidLibrary.aar
    contentFiles\any\net6.0-android31.0\MyAndroidLibrary.aar

`MyDotNetAssembly.aar` would contain any `.jar` files or
`AndroidResource` files packed inside. However, *other* `.aar` files
are supposed to sit next to `MyDotNetAssembly.dll`.

It was surprisingly difficult to work alongside NuGet's MSBuild
targets to get this to work.

1. In the `_CategorizeAndroidLibraries` MSBuild target, mark
   `TfmSpecificPackageFile="%(Pack)"` to be used in our
   `_IncludeAarInNuGetPackage` MSBuild target.

2. Add these files to `@(TfmSpecificPackageFileWithRecursiveDir)` and
   set `%(NuGetRecursiveDir)` to empty. Otherwise, these items can
   have `%(RecursiveDir)` set to some path, and this causes
   sub-directories in the `.nupkg` output.

I updated several tests for this case. I also updated usage of
`XASdkProject.OtherBuildItems` to use `Sources` instead.
`OtherBuildItems` adds the files to the `.csproj`, and we should be
testing our wildcards in `AutoImport.props`. Previously, some of these
items were being added twice in these tests.
@jonathanpeppers jonathanpeppers mentioned this issue May 27, 2022
Merged
@jonathanpeppers
Copy link
Member

@VincentUhlmann it appears that no one noticed this case wasn't right...

For now I'd workaround this with something like:

<ItemGroup>
  <AndroidLibrary Update="**\*.aar" Pack="false" />
  <None Update="**\*.aar" Pack="true" PackagePath="lib\$(TargetFramework)$(TargetPlatformVersion)" />
</ItemGroup>

I'll post this on a MAUI / Android known issues document. Thanks for catching this!

@jonathanpeppers
Copy link
Member

Linked to this problem at:

@VincentUhlmann
Copy link
Author

Glad I could help / contribute to this! Thanks also for the workaround, I will test as soon as I have time.

jonathanpeppers added a commit that referenced this issue May 31, 2022
@jonathanpeppers
[One .NET] pack AndroidLibrary .aar files in .nupkg (#7045)
868ef05 
Fixes: #7040

It appears we were missing a test case of:

1. `dotnet new androidlib`

2. Add an `.aar` file

3. `dotnet pack`

4. Assert that `lib\net6.0-android31.0\MyAndroidLibrary.aar` exists in
   the `.nupkg` output

We instead end up with "weird" output in the `.nupkg` like:

    lib\net6.0-android31.0\MyDotNetAssembly.dll
    lib\net6.0-android31.0\MyDotNetAssembly.xml
    lib\net6.0-android31.0\MyDotNetAssembly.aar
    content\MyAndroidLibrary.aar
    contentFiles\any\net6.0-android31.0\MyAndroidLibrary.aar

`MyDotNetAssembly.aar` would contain any `.jar` files or
`AndroidResource` files packed inside. However, *other* `.aar` files
are supposed to sit next to `MyDotNetAssembly.dll`.

It was surprisingly difficult to work alongside NuGet's MSBuild
targets to get this to work.

1. In the `_CategorizeAndroidLibraries` MSBuild target, mark
   `TfmSpecificPackageFile="%(Pack)"` to be used in our
   `_IncludeAarInNuGetPackage` MSBuild target.

2. Add these files to `@(TfmSpecificPackageFileWithRecursiveDir)` and
   set `%(NuGetRecursiveDir)` to empty. Otherwise, these items can
   have `%(RecursiveDir)` set to some path, and this causes
   sub-directories in the `.nupkg` output.

I updated several tests for this case. I also updated usage of
`XASdkProject.OtherBuildItems` to use `Sources` instead.
`OtherBuildItems` adds the files to the `.csproj`, and we should be
testing our wildcards in `AutoImport.props`. Previously, some of these
items were being added twice in these tests.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue May 31, 2022
@jonathanpeppers
[One .NET] pack AndroidLibrary .aar files in .nupkg
494692c 
Fixes: xamarin#7040

It appears we were missing a test case of:

1. `dotnet new androidlib`

2. Add an `.aar` file

3. `dotnet pack`

4. Assert that `lib\net6.0-android31.0\MyAndroidLibrary.aar` exists in
   the `.nupkg` output

We instead end up with "weird" output in the `.nupkg` like:

    lib\net6.0-android31.0\MyDotNetAssembly.dll
    lib\net6.0-android31.0\MyDotNetAssembly.xml
    lib\net6.0-android31.0\MyDotNetAssembly.aar
    content\MyAndroidLibrary.aar
    contentFiles\any\net6.0-android31.0\MyAndroidLibrary.aar

`MyDotNetAssembly.aar` would contain any `.jar` files or
`AndroidResource` files packed inside. However, *other* `.aar` files
are supposed to sit next to `MyDotNetAssembly.dll`.

It was surprisingly difficult to work alongside NuGet's MSBuild
targets to get this to work.

1. In the `_CategorizeAndroidLibraries` MSBuild target, mark
   `TfmSpecificPackageFile="%(Pack)"` to be used in our
   `_IncludeAarInNuGetPackage` MSBuild target.

2. Add these files to `@(TfmSpecificPackageFileWithRecursiveDir)` and
   set `%(NuGetRecursiveDir)` to empty. Otherwise, these items can
   have `%(RecursiveDir)` set to some path, and this causes
   sub-directories in the `.nupkg` output.

I updated several tests for this case. I also updated usage of
`XASdkProject.OtherBuildItems` to use `Sources` instead.
`OtherBuildItems` adds the files to the `.csproj`, and we should be
testing our wildcards in `AutoImport.props`. Previously, some of these
items were being added twice in these tests.
@jonathanpeppers jonathanpeppers mentioned this issue May 31, 2022
Merged
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue May 31, 2022
@jonathanpeppers
[One .NET] pack AndroidLibrary .aar files in .nupkg
3901e89 
Fixes: xamarin#7040

It appears we were missing a test case of:

1. `dotnet new androidlib`

2. Add an `.aar` file

3. `dotnet pack`

4. Assert that `lib\net6.0-android31.0\MyAndroidLibrary.aar` exists in
   the `.nupkg` output

We instead end up with "weird" output in the `.nupkg` like:

    lib\net6.0-android31.0\MyDotNetAssembly.dll
    lib\net6.0-android31.0\MyDotNetAssembly.xml
    lib\net6.0-android31.0\MyDotNetAssembly.aar
    content\MyAndroidLibrary.aar
    contentFiles\any\net6.0-android31.0\MyAndroidLibrary.aar

`MyDotNetAssembly.aar` would contain any `.jar` files or
`AndroidResource` files packed inside. However, *other* `.aar` files
are supposed to sit next to `MyDotNetAssembly.dll`.

It was surprisingly difficult to work alongside NuGet's MSBuild
targets to get this to work.

1. In the `_CategorizeAndroidLibraries` MSBuild target, mark
   `TfmSpecificPackageFile="%(Pack)"` to be used in our
   `_IncludeAarInNuGetPackage` MSBuild target.

2. Add these files to `@(TfmSpecificPackageFileWithRecursiveDir)` and
   set `%(NuGetRecursiveDir)` to empty. Otherwise, these items can
   have `%(RecursiveDir)` set to some path, and this causes
   sub-directories in the `.nupkg` output.

I updated several tests for this case. I also updated usage of
`XASdkProject.OtherBuildItems` to use `Sources` instead.
`OtherBuildItems` adds the files to the `.csproj`, and we should be
testing our wildcards in `AutoImport.props`. Previously, some of these
items were being added twice in these tests.
jonathanpeppers added a commit that referenced this issue Jun 1, 2022
@jonathanpeppers
[One .NET] pack AndroidLibrary .aar files in .nupkg (#7053)
7aff899 
Fixes: #7040

It appears we were missing a test case of:

1. `dotnet new androidlib`

2. Add an `.aar` file

3. `dotnet pack`

4. Assert that `lib\net6.0-android31.0\MyAndroidLibrary.aar` exists in
   the `.nupkg` output

We instead end up with "weird" output in the `.nupkg` like:

    lib\net6.0-android31.0\MyDotNetAssembly.dll
    lib\net6.0-android31.0\MyDotNetAssembly.xml
    lib\net6.0-android31.0\MyDotNetAssembly.aar
    content\MyAndroidLibrary.aar
    contentFiles\any\net6.0-android31.0\MyAndroidLibrary.aar

`MyDotNetAssembly.aar` would contain any `.jar` files or
`AndroidResource` files packed inside. However, *other* `.aar` files
are supposed to sit next to `MyDotNetAssembly.dll`.

It was surprisingly difficult to work alongside NuGet's MSBuild
targets to get this to work.

1. In the `_CategorizeAndroidLibraries` MSBuild target, mark
   `TfmSpecificPackageFile="%(Pack)"` to be used in our
   `_IncludeAarInNuGetPackage` MSBuild target.

2. Add these files to `@(TfmSpecificPackageFileWithRecursiveDir)` and
   set `%(NuGetRecursiveDir)` to empty. Otherwise, these items can
   have `%(RecursiveDir)` set to some path, and this causes
   sub-directories in the `.nupkg` output.

I updated several tests for this case. I also updated usage of
`XASdkProject.OtherBuildItems` to use `Sources` instead.
`OtherBuildItems` adds the files to the `.csproj`, and we should be
testing our wildcards in `AutoImport.props`. Previously, some of these
items were being added twice in these tests.
@xamarin xamarin locked as resolved and limited conversation to collaborators Jul 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@jpobst jpobst

Labels
needs-triage Issues that need to be assigned.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[One .NET] pack AndroidLibrary .aar files in .nupkg jonathanpeppers/xamarin-android
3 participants
@jpobst @jonathanpeppers @VincentUhlmann