-
Notifications
You must be signed in to change notification settings - Fork 533
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.
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
.aar file missing from NuGet package for .net6-android binding #7040
Comments
In .NET 6 projects, the More information is available here: |
@jonathanpeppers If I create a new binding library and Pack it from the default template with If I use Contents of Is this the expected result? |
Yeah, something seems wrong here, I'll test. |
Fixes: dotnet#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.
@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! |
Glad I could help / contribute to this! Thanks also for the workaround, I will test as soon as I have time. |
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.
Fixes: dotnet#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.
Fixes: dotnet#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.
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.
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
Did you find any workaround?
No response
Relevant log output
No response
The text was updated successfully, but these errors were encountered: