Distribuindo bibliotecas de ligações

Depois que uma biblioteca Java for associada a

• Referência do projeto - Se o projeto de associação e o projeto de aplicativo estiverem no mesmo arquivo de solução, usar a <ProjectReference> geralmente é a maneira mais fácil de consumir a associação.

• Pacote NuGet – um pacote NuGet é ideal para publicação pública ou para um ambiente de desenvolvimento distribuído interno que tem um servidor NuGet interno.

• Referência de arquivo – um aplicativo consumidor pode adicionar diretamente a <Reference> a uma associação .dll se nem o projeto de associação nem um servidor NuGet estiverem disponíveis.

Controlando opções de encadernação e empacotamento

Um projeto de biblioteca de associações tem duas opções para controlar se um <AndroidLibrary> é associado e redistribuído:

• Bind (truefalse/) - O padrão é true, o que significa que as associações gerenciadas são criadas para o .<AndroidLibrary> Definir como false significa que a biblioteca Java será incluída na saída, mas não terá ligações gerenciadas. Isso é útil se a biblioteca for uma dependência necessária de outra biblioteca Java, mas não será chamada de C#.

<!-- Java library will have C# bindings and be included in the output -->
<AndroidLibrary Include="okhttp-4.12.0.jar" />

<!-- Java library will not have C# bindings but will still be included in the output -->
<AndroidLibrary Include="okio-3.9.0.jar" Bind="false" />

• Pack (true/false) – o padrão trueé , o que significa que o especificado <AndroidLibrary> será incluído na saída (como um pacote NuGet). Definir como false significa que a biblioteca Java não será incluída na saída. Este é um cenário raro caso a dependência já esteja sendo fornecida por meios alternativos.

<!-- Java library will have C# bindings and be included in the output -->
<AndroidLibrary Include="okhttp-4.12.0.jar" />

<!-- Java library will have C# bindings but will *not* be included in the output -->
<AndroidLibrary Include="okio-3.9.0.jar" Pack="false" />

ProjectReference

Se o projeto de associação e o projeto de aplicativo estiverem no mesmo arquivo de solução, usar um <ProjectReference> geralmente é a maneira mais fácil de consumir a associação:

<ProjectReference Include="mybindinglib.csproj" />

O sistema de compilação será responsável por adicionar as associações gerenciadas, bem como quaisquer .jar/.aar arquivos ao projeto do aplicativo.

Pacote NuGet

Como uma propriedade herdada de projetos no estilo SDK do .NET, qualquer biblioteca de associações pode ser empacotada trivialmente em um pacote NuGet redistribuível usando o comando "Pack" no Visual Studio ou na linha de comando:

dotnet pack

A biblioteca de associações, bem como a biblioteca Java, serão incluídas no pacote NuGet:

Use o atributo documentado Pack acima para controlar quais bibliotecas Java são desejadas no pacote NuGet.

Os pacotes NuGet podem ser personalizados usando os elementos padrão do .NET MSBuild.

Referência de arquivo

Se nenhuma das opções acima for possível, a associação .dll poderá ser referenciada diretamente com um <Reference> elemento. Observe que todas as bibliotecas Java que fazem parte da saída do projeto de vinculação devem estar no mesmo diretório que a vinculação .dll.

Se você mover/copiar apenas a associação .dll para outro local e também não mover/copiar nenhum .jar/.dll arquivo, eles não terminarão em seu aplicativo e a associação falhará em tempo de execução.

Importante

No Xamarin.Android clássico, usar uma ação de item como EmbeddedJar colocaria o .jar arquivo dentro do .dll e apenas um arquivo seria necessário. O suporte para isso foi removido no .NET para Android porque aumentou muito o tempo de compilação do aplicativo para verificar e extrair arquivos de biblioteca Java incorporados. Todos os arquivos necessários .jar/.dll DEVEM estar localizados no mesmo diretório que a vinculação..dll