xamarin
/
xamarin-android
зеркало из https://github.com/xamarin/xamarin-android.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-android/Directory.Build.props

72 строки
4.1 KiB
Plaintext
Исходник Обычный вид История

[build] Update Bootstrap task projects to short-form style (#3928) Updates `build-tools/Xamarin.Android.BootstrapTasks`, `build-tools/xa-prep-tasks`, and other related or dependent projects to SDK-style short form style projects targeting `netstandard2.0`. A new top level `Directory.Build.props` file has been added to contain common properties that will be automatically imported everywhere. In the longer term, we can look to migrate content from `Configuration.props` to this file. New `$(PrepTasksAssembly)` and `$(BootstrapTasksAssembly)` MSBuild Properties have been added so that fewer changes will be required when updating the output path of these assemblies in the future. All files which reference these assemblies have been updated to use these new properties. `RunTests.targets` and `RunApkTests.targets` have been updated to explicitly import `Directory.Build.props` as we pass these files directly to `msbuild` invocations in certain cases. (`Directory.Build.props` was not being implicitly imported in those cases; I believe that implicit import only occurs when building a `.sln` or `.csproj`.) Finally, `$(CopyLocalLockFileAssemblies)`=True has been moved to `Directory.Build.props` file so that all of our short-form style projects will inherit this behavior.
2020-02-12 02:19:54 +03:00
<Project>
<PropertyGroup>
Bump to dotnet/installer/main@d5520378 8.0.200-alpha.1.22511.1 (#7451) Changes: https://github.com/dotnet/installer/compare/11f6b8f7129e34d5317f47ccbc110b2b11c05749...d552037815b75e01be05b6e8d269d54413363e7f Changes: https://github.com/dotnet/linker/compare/5f9bfd94d9c687207872ae03f751ea19704381c0...493ce626f3278b2d0fd883330bf11a64254981bb Changes: https://github.com/dotnet/runtime/compare/6d10e4c8bcd9f96ccd73748ff827561afa09af57...b8d49801fe03b96d2fead3d97a11dce1e723dd17 Context: https://github.com/dotnet/runtime/issues/77273 Context: https://github.com/dotnet/runtime/commit/e46523032d72c8b0d2b14ce4b14229a8c268a6e5 Context: https://github.com/dotnet/runtime/issues/77385 Build and run under .NET 8! .NET 8 is used by default for the default build. Running unit tests also requires installing .NET 6 and .NET 7 as well. Configure dotnet6 + dotnet7 + dotnet8 NuGet feeds. Run `darc update-dependencies --id 152596` to update the dotnet/installer version in `eng/Version.Details.xml`. (ID values come from [Maestro][0].) Update `AutoImport.props` to only evaluate default android items in .NET 8. Update `$(DotNetTargetFrameworkVersion)` to 8.0, and `$(DotNetStableTargetFramework)` to `net7.0`. (Technically .NET 7 isn't stable *yet*, but it will be soon enough…) Update `*.apkdesc` files so that unit tests pass. Update `PackagingTest.CheckIncludedAssemblies()` test to remove assemblies which are no longer included in .NET 8-based apps. Update `use-dot-net.yaml` to take a new `quality` parameter, and install .NET Core 3.1 quality=GA, not 3.1.417 specifically. Avoids the error: dotnet-install: Failed to locate the latest version in the channel '3.1.417' with 'preview' quality for 'dotnet-sdk', os: 'win', architecture: 'x64'. Update `src/Mono.Android.Export` to pass `MethodAttributes.Static | MethodAttributes.Public` to the `DynamicMethod` constructor, not just `MethodAttributes.Static`. This avoids a `NotSupportedException` under .NET 8; see also dotnet/runtime@e4652303 and dotnet/runtime#77273: System.NotSupportedException: Wrong MethodAttributes or CallingConventions for DynamicMethod. Only public, static, standard supported at System.Reflection.Emit.DynamicMethod.CheckConsistency(MethodAttributes attributes, CallingConventions callingConvention) at System.Reflection.Emit.DynamicMethod.Init(String name, MethodAttributes attributes, CallingConventions callingConvention, Type returnType, Type[] signature, Type owner, Module m, Boolean skipVisibility, Boolean transparentMethod) at System.Reflection.Emit.DynamicMethod..ctor(String name, MethodAttributes attributes, CallingConventions callingConvention, Type returnType, Type[] parameterTypes, Module m, Boolean skipVisibility) at Java.Interop.DynamicCallbackCodeGenerator.GenerateNativeCallbackDelegate() at Java.Interop.DynamicCallbackCodeGenerator.GetCallback() at Java.Interop.DynamicCallbackCodeGenerator.Create(MethodInfo method) at System.Reflection.MethodInvoker.InterpretedInvoke(Object obj, Span`1 args, BindingFlags invokeAttr) Update `XASdkTests.DotNetPublish()` for .NET 8. With 745214deb0 we asserted that builds using the *non-* latest target framework would use a `Mono.Android.dll` reference assembly *from the build*, not from an existing published/NuGet-provided `Microsoft.Android.Ref` package. This started failing because `$(TargetFramework)`=net7.0-android is no longer the latest framework and thus *should* be using published packages, not in-tree bits: Build should be using C:\a_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.Android.Ref.33\34.0.0-ci.pr.gh7451.52\ref\net7.0\Mono.Android.dll Expected: True But was: False Update the test to instead make this assertion only for the latest target framework (`net8.0-android`), skipping .NET 7. Remove an assertion of no build warnings under `net7.0`; this isn't currently possible, due to dotnet/runtime#77385. Update the `Microsoft.NETCore.App.Runtime.AOT.Cross` SDK package names when `$(AotAssemblies)`=True; the names do not (yet?) include the .NET version in the package names. When installing multiple .NET SDKs into a single folder with the `dotnet-install.{.sh,ps1}` script -- needed to run the unit tests -- you can hit an issue where `dotnet` no longer runs: dotnet --info Exited with code: 137 The problem is that the `dotnet` binary can get overwritten by an older .NET, and be completely broken. The solution is: 1. Install the newest .NET first, followed by any older versions 2. Use `dotnet-install.ps1 -SkipNonVersionedFiles` or `dotnet-install.sh --skip-non-versioned-files` so the `dotnet` binary isn't overwritten This results in the newest .NET SDK, with side-by-side older .NET SDKs installed as well. Rename `tests/api-compatibility/acceptable-breakages-vReference-net7.0.txt` to use `-net8.0`, as the default `$(TargetFramework)` for `Mono.Android.dll` changed. [0]: https://maestro-prod.westus2.cloudapp.azure.com/3074/https:%2F%2Fgithub.com%2Fdotnet%2Finstaller/latest/graph
2022-10-26 22:17:44 +03:00
<DotNetTargetFrameworkVersion>8.0</DotNetTargetFrameworkVersion>
[build] Use variables for `net6.0` where possible (#6947) Context: https://github.com/xamarin/xamarin-android/pull/6598 In preparation for .NET 7 we should remove as many hard-coded instances of `net6.0` as possible. I've cherry-picked a handful of commits from @jonathanpeppers over to simplify that diff and to apply these generic changes sooner than later. New variables, MSBuild properties, and YAML parameters are now used in place of explicit `net6.0` mentions. Some conditions have also been flipped to check against `MonoAndroid` rather than `net6.0`. The `$(RollForward)` property has also been set to `Major` globally. Context: https://natemcmaster.com/blog/2019/01/09/netcore-primitives-3/ Context: https://github.com/dotnet/designs/blob/main/accepted/2019/runtime-binding.md#rollforward Previously when running `dotnet` on a machine with *only* .NET 7.0 and no .NET 6.0, you could hit: It was not possible to find any compatible framework version The framework 'Microsoft.NETCore.App', version '6.0.0' was not found. To solve this, we need our `*.runtimeconfig.json` to allow things to automatically roll forward to .NET 7.0 if .NET 6.0 is not found. If we set `$(RollForward)` to `Major`: > `Major` -- Roll forward to lowest higher major version, and lowest > minor version, if requested major version is missing. If the > requested major version is present, then the `Minor` policy is used. I think this will make things work indefinitely for new .NET versions. It should be OK to set this repo-wide. Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
2022-04-21 18:32:29 +03:00
<DotNetTargetFramework>net$(DotNetTargetFrameworkVersion)</DotNetTargetFramework>
<DotNetAndroidTargetFramework>$(DotNetTargetFramework)-android</DotNetAndroidTargetFramework>
<!-- Used for bootstrap, command-line tooling, and desktop NUnit projects -->
Bump to dotnet/installer/main@d5520378 8.0.200-alpha.1.22511.1 (#7451) Changes: https://github.com/dotnet/installer/compare/11f6b8f7129e34d5317f47ccbc110b2b11c05749...d552037815b75e01be05b6e8d269d54413363e7f Changes: https://github.com/dotnet/linker/compare/5f9bfd94d9c687207872ae03f751ea19704381c0...493ce626f3278b2d0fd883330bf11a64254981bb Changes: https://github.com/dotnet/runtime/compare/6d10e4c8bcd9f96ccd73748ff827561afa09af57...b8d49801fe03b96d2fead3d97a11dce1e723dd17 Context: https://github.com/dotnet/runtime/issues/77273 Context: https://github.com/dotnet/runtime/commit/e46523032d72c8b0d2b14ce4b14229a8c268a6e5 Context: https://github.com/dotnet/runtime/issues/77385 Build and run under .NET 8! .NET 8 is used by default for the default build. Running unit tests also requires installing .NET 6 and .NET 7 as well. Configure dotnet6 + dotnet7 + dotnet8 NuGet feeds. Run `darc update-dependencies --id 152596` to update the dotnet/installer version in `eng/Version.Details.xml`. (ID values come from [Maestro][0].) Update `AutoImport.props` to only evaluate default android items in .NET 8. Update `$(DotNetTargetFrameworkVersion)` to 8.0, and `$(DotNetStableTargetFramework)` to `net7.0`. (Technically .NET 7 isn't stable *yet*, but it will be soon enough…) Update `*.apkdesc` files so that unit tests pass. Update `PackagingTest.CheckIncludedAssemblies()` test to remove assemblies which are no longer included in .NET 8-based apps. Update `use-dot-net.yaml` to take a new `quality` parameter, and install .NET Core 3.1 quality=GA, not 3.1.417 specifically. Avoids the error: dotnet-install: Failed to locate the latest version in the channel '3.1.417' with 'preview' quality for 'dotnet-sdk', os: 'win', architecture: 'x64'. Update `src/Mono.Android.Export` to pass `MethodAttributes.Static | MethodAttributes.Public` to the `DynamicMethod` constructor, not just `MethodAttributes.Static`. This avoids a `NotSupportedException` under .NET 8; see also dotnet/runtime@e4652303 and dotnet/runtime#77273: System.NotSupportedException: Wrong MethodAttributes or CallingConventions for DynamicMethod. Only public, static, standard supported at System.Reflection.Emit.DynamicMethod.CheckConsistency(MethodAttributes attributes, CallingConventions callingConvention) at System.Reflection.Emit.DynamicMethod.Init(String name, MethodAttributes attributes, CallingConventions callingConvention, Type returnType, Type[] signature, Type owner, Module m, Boolean skipVisibility, Boolean transparentMethod) at System.Reflection.Emit.DynamicMethod..ctor(String name, MethodAttributes attributes, CallingConventions callingConvention, Type returnType, Type[] parameterTypes, Module m, Boolean skipVisibility) at Java.Interop.DynamicCallbackCodeGenerator.GenerateNativeCallbackDelegate() at Java.Interop.DynamicCallbackCodeGenerator.GetCallback() at Java.Interop.DynamicCallbackCodeGenerator.Create(MethodInfo method) at System.Reflection.MethodInvoker.InterpretedInvoke(Object obj, Span`1 args, BindingFlags invokeAttr) Update `XASdkTests.DotNetPublish()` for .NET 8. With 745214deb0 we asserted that builds using the *non-* latest target framework would use a `Mono.Android.dll` reference assembly *from the build*, not from an existing published/NuGet-provided `Microsoft.Android.Ref` package. This started failing because `$(TargetFramework)`=net7.0-android is no longer the latest framework and thus *should* be using published packages, not in-tree bits: Build should be using C:\a_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.Android.Ref.33\34.0.0-ci.pr.gh7451.52\ref\net7.0\Mono.Android.dll Expected: True But was: False Update the test to instead make this assertion only for the latest target framework (`net8.0-android`), skipping .NET 7. Remove an assertion of no build warnings under `net7.0`; this isn't currently possible, due to dotnet/runtime#77385. Update the `Microsoft.NETCore.App.Runtime.AOT.Cross` SDK package names when `$(AotAssemblies)`=True; the names do not (yet?) include the .NET version in the package names. When installing multiple .NET SDKs into a single folder with the `dotnet-install.{.sh,ps1}` script -- needed to run the unit tests -- you can hit an issue where `dotnet` no longer runs: dotnet --info Exited with code: 137 The problem is that the `dotnet` binary can get overwritten by an older .NET, and be completely broken. The solution is: 1. Install the newest .NET first, followed by any older versions 2. Use `dotnet-install.ps1 -SkipNonVersionedFiles` or `dotnet-install.sh --skip-non-versioned-files` so the `dotnet` binary isn't overwritten This results in the newest .NET SDK, with side-by-side older .NET SDKs installed as well. Rename `tests/api-compatibility/acceptable-breakages-vReference-net7.0.txt` to use `-net8.0`, as the default `$(TargetFramework)` for `Mono.Android.dll` changed. [0]: https://maestro-prod.westus2.cloudapp.azure.com/3074/https:%2F%2Fgithub.com%2Fdotnet%2Finstaller/latest/graph
2022-10-26 22:17:44 +03:00
<DotNetStableTargetFramework>net7.0</DotNetStableTargetFramework>
[build] Update Bootstrap task projects to short-form style (#3928) Updates `build-tools/Xamarin.Android.BootstrapTasks`, `build-tools/xa-prep-tasks`, and other related or dependent projects to SDK-style short form style projects targeting `netstandard2.0`. A new top level `Directory.Build.props` file has been added to contain common properties that will be automatically imported everywhere. In the longer term, we can look to migrate content from `Configuration.props` to this file. New `$(PrepTasksAssembly)` and `$(BootstrapTasksAssembly)` MSBuild Properties have been added so that fewer changes will be required when updating the output path of these assemblies in the future. All files which reference these assemblies have been updated to use these new properties. `RunTests.targets` and `RunApkTests.targets` have been updated to explicitly import `Directory.Build.props` as we pass these files directly to `msbuild` invocations in certain cases. (`Directory.Build.props` was not being implicitly imported in those cases; I believe that implicit import only occurs when building a `.sln` or `.csproj`.) Finally, `$(CopyLocalLockFileAssemblies)`=True has been moved to `Directory.Build.props` file so that all of our short-form style projects will inherit this behavior.
2020-02-12 02:19:54 +03:00
<TargetFrameworkNETStandard>netstandard2.0</TargetFrameworkNETStandard>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<BuildOutputDirectory>$(MSBuildThisFileDirectory)bin\$(Configuration)\</BuildOutputDirectory>
<BootstrapOutputDirectory>$(MSBuildThisFileDirectory)bin\Build$(Configuration)\</BootstrapOutputDirectory>
<TestOutputDirectory>$(MSBuildThisFileDirectory)bin\Test$(Configuration)\</TestOutputDirectory>
<BootstrapTasksAssembly>$(BootstrapOutputDirectory)$(TargetFrameworkNETStandard)\Xamarin.Android.Tools.BootstrapTasks.dll</BootstrapTasksAssembly>
<PrepTasksAssembly>$(BootstrapOutputDirectory)$(TargetFrameworkNETStandard)\xa-prep-tasks.dll</PrepTasksAssembly>
[build] Move dotnet sandbox to build output directory (#6797) Moves the "sandbox" installation of `dotnet` that we use for testing purposes from `$HOME/android-toolchain/dotnet` into the build tree at `bin/$(Configuration)/dotnet`. While this could lead to increased disk usage across some local build environments it provides a handful of benefits: Every time `make prepare` or `dotnet build -t:Prepare` runs we would remove `$HOME/android-toolchain/dotnet` and start fresh. Having it in a single "global" location is not too desirable when working out of multiple checkout locations (fork vs non-fork for example), or when using multiple build configurations at the same time. This sandbox can also now more easily be removed with a `git clean` if desirable; we had no "automatic" way to remove the `$HOME/android-toolchain` installation location previously. This move will also make it easier to eventually structure our .NET build output in a way that will allow it to be tested without having to pack and unpack `.nupkg` files.
2022-03-01 18:22:39 +03:00
<DotNetPreviewPath Condition=" '$(DotNetPreviewPath)' == '' ">$(BuildOutputDirectory)dotnet\</DotNetPreviewPath>
<DotNetPreviewTool Condition=" '$(DotNetPreviewTool)' == '' ">$(DotNetPreviewPath)dotnet</DotNetPreviewTool>
[build] Update Bootstrap task projects to short-form style (#3928) Updates `build-tools/Xamarin.Android.BootstrapTasks`, `build-tools/xa-prep-tasks`, and other related or dependent projects to SDK-style short form style projects targeting `netstandard2.0`. A new top level `Directory.Build.props` file has been added to contain common properties that will be automatically imported everywhere. In the longer term, we can look to migrate content from `Configuration.props` to this file. New `$(PrepTasksAssembly)` and `$(BootstrapTasksAssembly)` MSBuild Properties have been added so that fewer changes will be required when updating the output path of these assemblies in the future. All files which reference these assemblies have been updated to use these new properties. `RunTests.targets` and `RunApkTests.targets` have been updated to explicitly import `Directory.Build.props` as we pass these files directly to `msbuild` invocations in certain cases. (`Directory.Build.props` was not being implicitly imported in those cases; I believe that implicit import only occurs when building a `.sln` or `.csproj`.) Finally, `$(CopyLocalLockFileAssemblies)`=True has been moved to `Directory.Build.props` file so that all of our short-form style projects will inherit this behavior.
2020-02-12 02:19:54 +03:00
<!-- Copy PackageReference content to OutputDir for our build tasks, tests, and installer creation logic. This no longer happens by default in short-form projects. -->
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
[build] set $(ProduceReferenceAssemblyInOutDir)=True (#6744) Context: https://docs.microsoft.com/dotnet/core/compatibility/sdk/6.0/write-reference-assemblies-to-obj Context: https://github.com/dotnet/msbuild/issues/7355 Context: https://github.com/xamarin/java.interop/commit/7dc270dbb83948b278bee38fc83bf9ae5cd42a7e Using the latest internal builds of Visual Studio, you hit the build error when building xamarin-android: error MSB4018: The "CreateFrameworkListFile" task failed unexpectedly. [C:\src\xamarin-android\build-tools\create-packs\Microsoft.Android.Ref.proj] [C:\src\xamarin-android\build-tools\create-packs\Microsoft.Android.Sdk.proj] error MSB4018: System.IO.FileNotFoundException: Could not find file 'C:\src\xamarin-android\bin\Release\lib\xamarin.android\xbuild-frameworks\Microsoft.Android\net6.0-android32\ref\Mono.Android.dll'. This was a breaking change in MSBuild: > ### Old behavior > Since reference assemblies were added, the .NET SDK has written > reference assemblies to the `ref` directory in the `OutDir` > directory of the compilation. > > ### New behavior > Now, reference assemblies are written to the `refint` directory of > the `IntermediateOutputPath` directory by default, like many other > intermediate artifacts. > > ### Reason for change > Reference assemblies are generally not run-time assets, and so don't > belong in the `OutDir` directory by default. Since we *are* using the reference assembly as build output, I think we *should* put the file in `bin`. Let's set `$(ProduceReferenceAssemblyInOutDir)`=True to get the old behavior. I could not figure out how to use `$(TargetRefPath)` here, as different projects are using the files than producing them… If the same project was building `Mono.Android.dll` as packing it, we could use that property and not have to know if the file is in `bin`/`obj`.
2022-02-16 00:16:10 +03:00
<!-- Ensure reference assemblies copied to bin -->
<ProduceReferenceAssemblyInOutDir>true</ProduceReferenceAssemblyInOutDir>
[build] Use variables for `net6.0` where possible (#6947) Context: https://github.com/xamarin/xamarin-android/pull/6598 In preparation for .NET 7 we should remove as many hard-coded instances of `net6.0` as possible. I've cherry-picked a handful of commits from @jonathanpeppers over to simplify that diff and to apply these generic changes sooner than later. New variables, MSBuild properties, and YAML parameters are now used in place of explicit `net6.0` mentions. Some conditions have also been flipped to check against `MonoAndroid` rather than `net6.0`. The `$(RollForward)` property has also been set to `Major` globally. Context: https://natemcmaster.com/blog/2019/01/09/netcore-primitives-3/ Context: https://github.com/dotnet/designs/blob/main/accepted/2019/runtime-binding.md#rollforward Previously when running `dotnet` on a machine with *only* .NET 7.0 and no .NET 6.0, you could hit: It was not possible to find any compatible framework version The framework 'Microsoft.NETCore.App', version '6.0.0' was not found. To solve this, we need our `*.runtimeconfig.json` to allow things to automatically roll forward to .NET 7.0 if .NET 6.0 is not found. If we set `$(RollForward)` to `Major`: > `Major` -- Roll forward to lowest higher major version, and lowest > minor version, if requested major version is missing. If the > requested major version is present, then the `Minor` policy is used. I think this will make things work indefinitely for new .NET versions. It should be OK to set this repo-wide. Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
2022-04-21 18:32:29 +03:00
<!-- Ensure command-line apps can use a newer .NET -->
<RollForward>Major</RollForward>
[build] Fix issues preventing parallel builds (#7068) Changes: https://github.com/xamarin/java.interop/compare/d0ef9e3228472c9673451c924df50441c0258706...51c3dae766281a1c5b9e122304aabdd43377c044 * xamarin/java.interop@51c3dae7: [Java.Interop-MonoAndroid.csproj] Add jnienv-gen ProjectReference (#990) Remove all instances of `dotnet build -m:1` from the build system, and fix all issues which prevent it from appearing to work. (Testing was via 4 consecutive CI builds without errors. This does not mean it's a complete fix, but it seems good enough to merge.) Fixes include: Using `build-tools/create-android-api` (9987069b) to build `JNIEnv.g.cs` only once, instead of once per `$(TargetFrameworkVersion)`. This prevents sharing violations when multiple `Mono.Android.csproj` builds attempt to create it simultaneously: System.IO.IOException: The process cannot access the file 'C:\a\_work\1\s\src\Mono.Android\Android.Runtime\JNIEnv.g.cs' because it is being used by another process. *Serialize* gradlew-using project references, such that `r8.csproj` has a `@(ProjectReference)` to `manifestmerger.csproj`, and `manifestmerger.csproj` has a `@(ProjectReference)` to `apksigner.csproj`. `gradlew` execution can time out when multiple `gradlew` instances are run concurrently, even if `gradlew --no-daemon` is used. Serializing these project references avoids the errors: org.gradle.launcher.daemon.client.DaemonConnectionException: Timeout waiting to connect to the Gradle daemon. The file lock is held by a different Gradle process. Add a `@(ProjectReference)` on `Microsoft.Android.Sdk.ILLink.csproj` to `Xamarin.Android.Build.Tasks.csproj`, so that `Xamarin.Android.Build.Tasks\obj\$(Configuration)\Profile.g.cs` is available for compilation. Fixes: CSC error CS2001: Source file 'C:\code\xamarin-android\src\Microsoft.Android.Sdk.ILLink\..\Xamarin.Android.Build.Tasks\obj\Debug\Profile.g.cs' could not be found. Commit xamarin/java.interop@51c3dae7, which adds a `@(ProjectReference)` on `Java.Interop-MonoAndroid.csproj` to `jnienv-gen.csproj`, which ensures that `jnienv-gen.exe` exists when `Java.Interop-MonoAndroid.csproj` is built. Fix errors such as: '"C:\a\_work\1\s\external\Java.Interop\bin\BuildRelease\jnienv-gen.exe"' is not recognized as an internal or external command, operable program or batch file. or …/xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop.targets(19,5): error MSB3073: The command "mono "…/xamarin-android/external/Java.Interop/bin/BuildDebug/jnienv-gen.exe" Java.Interop/JniEnvironment.g.cs obj/Debug/jni.c" exited with code 2. […/xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop-MonoAndroid.csproj]
2022-06-14 04:02:08 +03:00
<!-- We don't need to be warned that we are using a preview .NET -->
<SuppressNETCoreSdkPreviewMessage>true</SuppressNETCoreSdkPreviewMessage>
Bump to dotnet/installer/release/7.0.1xx@11f6b8f 7.0.100-rc.2.22459.2 (#7367) Changes: https://github.com/dotnet/installer/compare/dd355bb...11f6b8f Updates: * Microsoft.Dotnet.Sdk.Internal: from 7.0.100-rc.2.22457.6 to 7.0.100-rc.2.22459.2 ~~ Other Changes ~~ * Enable `$(DisableTransitiveFrameworkReferenceDownloads)` in `Directory.Build.targets` This transitive package restores for packs like `Microsoft.AspNetCore.App.Ref`. Otherwise we would need the 6.0.10 feed for ASP.NET Core packages. * Update the dotnet/runtime feed to `darc-pub-dotnet-runtime-8c6bcad`. This contains 6.0.10 runtime packages Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
2022-09-16 16:28:00 +03:00
<!-- Disables the transitive restore of packages like Microsoft.AspNetCore.App.Ref, Microsoft.WindowsDesktop.App.Ref -->
<DisableTransitiveFrameworkReferenceDownloads>true</DisableTransitiveFrameworkReferenceDownloads>
[build] Update Bootstrap task projects to short-form style (#3928) Updates `build-tools/Xamarin.Android.BootstrapTasks`, `build-tools/xa-prep-tasks`, and other related or dependent projects to SDK-style short form style projects targeting `netstandard2.0`. A new top level `Directory.Build.props` file has been added to contain common properties that will be automatically imported everywhere. In the longer term, we can look to migrate content from `Configuration.props` to this file. New `$(PrepTasksAssembly)` and `$(BootstrapTasksAssembly)` MSBuild Properties have been added so that fewer changes will be required when updating the output path of these assemblies in the future. All files which reference these assemblies have been updated to use these new properties. `RunTests.targets` and `RunApkTests.targets` have been updated to explicitly import `Directory.Build.props` as we pass these files directly to `msbuild` invocations in certain cases. (`Directory.Build.props` was not being implicitly imported in those cases; I believe that implicit import only occurs when building a `.sln` or `.csproj`.) Finally, `$(CopyLocalLockFileAssemblies)`=True has been moved to `Directory.Build.props` file so that all of our short-form style projects will inherit this behavior.
2020-02-12 02:19:54 +03:00
</PropertyGroup>
[.NET 5] Update NuGet package version scheme (#4635) Updates the version for all `.nupkg` files we are generating for .NET 5 to follow the dotnet [SDK versioning scheme][0]. For more information, see `Documentation/guides/DotNet5.md`. Versioning for release candidates has not yet been automated. This commit only introduces the following two package version types: * 10.0.100-ci.branchname.commitdistance+sha.1b2c3d4e * 10.0.100-ci.pr.gh1234.commitdistance+sha.1b2c3d4f Version file generation has been updated to generate new files for our `.nupkg`s. `Mono.Android.dll` assembly info generation has also been updated to include different version information depending on `$(TargetFramework)`. Additionally, this bumps `$(ProductVersion)` to 10.4.100. This was done because `$(ProductVersion)` was moved from `Configuration.props` to `Directory.Build.props`, which will cause a "reset" of commitdistance. We don't want our internal installer versions to go *backwards* from 10.4.99.58 (for af3f1243) to 10.4.99.0. Using 10.4.100 means the version number only increases. [0]: https://github.com/dotnet/designs/blob/master/accepted/2018/sdk-version-scheme.md
2020-04-30 22:50:21 +03:00
<PropertyGroup>
Bump $(ProductVersion) to 13.2.99 (Commercial) Xamarin.Android v13.1\2 is being tracked in the [xamarin-android/d17-5][0] branch, which was branched from commit fc621d50. Bump `$(ProductVersion)` to 13.2.99 to track development progress of the *next* version of Xamarin.Android. [0]: https://github.com/xamarin/xamarin-android/commits/d17-5
2022-12-13 06:31:32 +03:00
<ProductVersion>13.2.99</ProductVersion>
[One .NET] exclude MSBuild targets for .dll.config files (#4896) Running under .NET 5+, the `BuildTest.BuildBasicApplicationCheckConfigFiles()` test fails with: UnnamedProject.dll.config was must be copied to Intermediate directory Expected: True But was: False After review, it doesn't seem like Xamarin.Android needs to support `.dll.config` files in .NET 5+ at all. 1. `<dllmap/>` is not supported. It was a feature of Mono. [`NativeLibrary`][0] is the replacement, but only exists in .NET Core 3.0+. 2. `appSettings` only work via a compat NuGet package: <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.7.0" /> However, this NuGet package does not work in the current Xamarin.Android (it throws `PlatformNotSupportedException`), and there is no other mechanism to support `appSettings`. All MSBuild targets related to `.config` files have been moved to `Xamarin.Android.Legacy.targets`. If a .NET 5+ build encounters a `.dll.config` file, an XA1024 warning will be generated: warning XA1024: Ignoring configuration file 'Foo.dll.config'. .NET configuration files are not supported in Xamarin.Android projects that target .NET 5 or higher. This is unfortunately an un-actionable warning message, so we may want to reconsider this approach. TODO/Possible answer: if we ever have a mechanism to support NuGet package creation a'la `dotnet pack`, we could emit the XA1024 warning at package creation if the `.dll.config` is included in the NuGet. I added updated tests around the`_CopyConfigFiles` MSBuild target to run under `dotnet` context. [0]: https://docs.microsoft.com/dotnet/api/system.runtime.interopservices.nativelibrary
2020-07-14 19:12:51 +03:00
<!-- NuGet package version numbers. See Documentation/guides/OneDotNet.md.
[.NET 5] Update NuGet package version scheme (#4635) Updates the version for all `.nupkg` files we are generating for .NET 5 to follow the dotnet [SDK versioning scheme][0]. For more information, see `Documentation/guides/DotNet5.md`. Versioning for release candidates has not yet been automated. This commit only introduces the following two package version types: * 10.0.100-ci.branchname.commitdistance+sha.1b2c3d4e * 10.0.100-ci.pr.gh1234.commitdistance+sha.1b2c3d4f Version file generation has been updated to generate new files for our `.nupkg`s. `Mono.Android.dll` assembly info generation has also been updated to include different version information depending on `$(TargetFramework)`. Additionally, this bumps `$(ProductVersion)` to 10.4.100. This was done because `$(ProductVersion)` was moved from `Configuration.props` to `Directory.Build.props`, which will cause a "reset" of commitdistance. We don't want our internal installer versions to go *backwards* from 10.4.99.58 (for af3f1243) to 10.4.99.0. Using 10.4.100 means the version number only increases. [0]: https://github.com/dotnet/designs/blob/master/accepted/2018/sdk-version-scheme.md
2020-04-30 22:50:21 +03:00
Rules:
[One .NET] version .NET 6 packages with Android API level (#5924) Our current versions for .NET 6 packages use the Android OS Version version number, with `XXX` is the git "commit distance": 11.0.200-preview.4.XXX e.g. (via xamarin/xamarin-android@c1fafcb1): Microsoft.Android.Runtime.android-arm64.11.0.200-preview.4.251.nupkg This is the only place where Android "11" remains, as we have been using the Android API level for all other versions in .NET 6, e.g. commit 91498d55. We should instead use an API-level, such as: 30.0.100-preview.4.XXX as in: Microsoft.Android.Runtime.android-arm64.30.0.100-ci.pr.gh5924.1.nupkg We believe that this will make things less confusing, as this matches the Android Target Framework Moniker as well: net6.0-android30
2021-05-12 02:18:05 +03:00
* Major/Minor match Android stable API level, such as 30.0 for API 30.
[.NET 5] Update NuGet package version scheme (#4635) Updates the version for all `.nupkg` files we are generating for .NET 5 to follow the dotnet [SDK versioning scheme][0]. For more information, see `Documentation/guides/DotNet5.md`. Versioning for release candidates has not yet been automated. This commit only introduces the following two package version types: * 10.0.100-ci.branchname.commitdistance+sha.1b2c3d4e * 10.0.100-ci.pr.gh1234.commitdistance+sha.1b2c3d4f Version file generation has been updated to generate new files for our `.nupkg`s. `Mono.Android.dll` assembly info generation has also been updated to include different version information depending on `$(TargetFramework)`. Additionally, this bumps `$(ProductVersion)` to 10.4.100. This was done because `$(ProductVersion)` was moved from `Configuration.props` to `Directory.Build.props`, which will cause a "reset" of commitdistance. We don't want our internal installer versions to go *backwards* from 10.4.99.58 (for af3f1243) to 10.4.99.0. Using 10.4.100 means the version number only increases. [0]: https://github.com/dotnet/designs/blob/master/accepted/2018/sdk-version-scheme.md
2020-04-30 22:50:21 +03:00
* Bump first digit of the patch version for feature releases (and reset the first two digits to 0)
-->
$(AndroidPackVersionSuffix)=preview.1; net8 is 34.0.0.preview.1 (#7392) 5374e3a59cb516332ce1ff6d96d261dddc769b3c Context: https://github.com/xamarin/xamarin-android/tree/release/7.0.1xx We branched for .NET 7 from 5374e3a5 into release/7.0.1xx; the main branch is now .NET 8. Update xamarin-android/main's version number to 34.0.0-preview.1. We should also only push packages from main to the `dotnet8` feed.
2022-09-18 18:58:53 +03:00
<AndroidPackVersion>34.0.0</AndroidPackVersion>
$(AndroidPackVersionSuffix)=preview.2; net8 is 34.0.0-preview.2 (#7761) Context: https://github.com/xamarin/xamarin-android/tree/release/8.0.1xx-preview1 We branched for .NET 8 preview 1 from 34af985 into `release/8.0.1xx-preview1`. Update xamarin-android/main's version number to 34.0.0-preview.2 for .NET 8 preview 2.
2023-02-02 23:28:05 +03:00
<AndroidPackVersionSuffix>preview.2</AndroidPackVersionSuffix>
[.NET 5] Update NuGet package version scheme (#4635) Updates the version for all `.nupkg` files we are generating for .NET 5 to follow the dotnet [SDK versioning scheme][0]. For more information, see `Documentation/guides/DotNet5.md`. Versioning for release candidates has not yet been automated. This commit only introduces the following two package version types: * 10.0.100-ci.branchname.commitdistance+sha.1b2c3d4e * 10.0.100-ci.pr.gh1234.commitdistance+sha.1b2c3d4f Version file generation has been updated to generate new files for our `.nupkg`s. `Mono.Android.dll` assembly info generation has also been updated to include different version information depending on `$(TargetFramework)`. Additionally, this bumps `$(ProductVersion)` to 10.4.100. This was done because `$(ProductVersion)` was moved from `Configuration.props` to `Directory.Build.props`, which will cause a "reset" of commitdistance. We don't want our internal installer versions to go *backwards* from 10.4.99.58 (for af3f1243) to 10.4.99.0. Using 10.4.100 means the version number only increases. [0]: https://github.com/dotnet/designs/blob/master/accepted/2018/sdk-version-scheme.md
2020-04-30 22:50:21 +03:00
</PropertyGroup>
[ci] Enable signing for .NET 6 artifacts (#5529) Context: https://github.com/xamarin/yaml-templates/tree/564100f2aa923ee4db4b69cc45a622822643309b/sign-artifacts Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/650/Enabling-Signing-in-Your-Projects The structure of our YAML pipeline has been updated to enable signing for all relevant .NET 6 artifacts. The new pipeline hierarchy is described below: mac_build ... sign nupkgs create net6 .pkg download signed .nupkgs push signed .nupkgs to feed harden/sign mach-o binaries create .pkg sign .pkg notarize .pkg publish .pkg create net6 .msi download signed .nupkgs download notarized .pkg create and sign .msi upload .msi and .pkg to blob storage The `dotnet_installers` stage now starts with a templated job which will sign all `.nupkg` files created by the `mac_build` stage. These signed packages are then downloaded by a new macOS job that will push them to a feed and use them to create, sign, and notarize the .NET 6 `.pkg` file. Finally, the job which previously created our .NET 6 `.msi` has been updated to wait for the result of the .NET 6 `.pkg` creation job. This job will now consume the signed `.nupkg` files to produce a signed `.msi`, and upload both the signed `.pkg` and `.msi` files to blob storage. None of the `MicroBuild` tasks/targets will run during local builds, so we do not need to worry about additional environment provisioning when creating these installers locally. In order to test locally, the MicroBuild signing NuGet needs to be installed locally and either the `$(MicroBuildOverridePluginDirectory)` or `$(MicroBuildPluginDirectory)` properties must be set and point to the folder where the signing NuGet was installed. See the ["Enabling signing in your projects" wiki][0] above for more information. The new `SignList.xml` file is used by the `.nupkg` signing job. The content of this file controls which certs are used to sign which files. Anything that was signed through an alternate source should be added to the `@(Skip)` ItemGroup. Any third party file that needs signing should be added to the `@(ThirdParty)` ItemGroup. [0]: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/650/Enabling-Signing-in-Your-Projects
2021-01-27 00:22:33 +03:00
<!-- Common <PackageReference/> versions -->
<PropertyGroup>
Bump to mono/mono.posix@d8994ca, xamarin/LibZipSharp@98e9173 (#7309) Changes: https://github.com/mono/mono.posix/compare/e1269a564a022b143769785714968a52091c10a4...d8994caaf29f0a95022ee4d1d51ae0a55150ce92 * mono/mono.posix@d8994ca: Remove Windows support completely for now Fixes an issue in which Mono.Unix would try to resolve `libc` P/Invokes by looking for the `msvcrt` library on Unix machines. * mono/mono.posix@74d504f: Fix yaml template path * mono/mono.posix@127cf9e: [build] Don't rebuild managed code on packaging time on Windows Changes: https://github.com/xamarin/LibZipSharp/compare/2.0.4...2.0.7 * xamarin/LibZipSharp@98e9173: Bump version to 2.0.7 * xamarin/LibZipSharp@6e1e1b3: Localized file check-in by OneLocBuild Task: Build definition ID 11678: Build ID 6581869 (#119) * xamarin/LibZipSharp@1c05430: LEGO: Merge pull request 118 * xamarin/LibZipSharp@06d44d8: Localized file check-in by OneLocBuild Task: Build definition ID 11678: Build ID 6570668 (#117) * xamarin/LibZipSharp@37f3894: LEGO: Merge pull request 116 * xamarin/LibZipSharp@6c0edc5: Update libzip and zlib submodules (#115) * xamarin/LibZipSharp@acd9a54: [Localization] Switch from xlf to resx files (#112) * xamarin/LibZipSharp@3cece80: LEGO: Merge pull request 114 * xamarin/LibZipSharp@fe336b4: LEGO: Merge pull request 113 * xamarin/LibZipSharp@9aee99a: [Localization] Add OneLocBuild job (#111) * xamarin/LibZipSharp@bdfa9f8: Bump Mono.Unix to 7.1.0-final.1.21458.1 (#110) Changes: https://github.com/xamarin/monodroid/compare/210073e19b9aa339d2099260e724c1f60df6fd70...100ccf969e58a633ec85af7627110bab6e9fe13d * xamarin/monodroid@100ccf969: Bump to xamarin/androidtools@81486ab, xamarin/android-sdk-installer@8cac7ea (#1264) Changes: https://github.com/xamarin/xamarin-android-tools/compare/9c641b3e08e56db37467a64a2c5de2c7f7ddb3ef...29f11f2a304376bfa96de999a78083fe5a8174c6 * xamarin/xamarin-android-tools@29f11f2 Bump to mono/mono.posix@d8994ca, xamarin/LibZipSharp@98e9173 (#193) * xamarin/xamarin-android-tools@7cfe683 [ci] Use Microsoft.SourceLink.GitHub (#192) * xamarin/xamarin-android-tools@01a0dde [Localization] Import translated resx files (#189) * xamarin/xamarin-android-tools@cc715d9 [Xamarin.Android.Tools.AndroidSdk] Permit NDK r25 (#190) * xamarin/xamarin-android-tools@3c55e9a Avoid `Environment.SpecialFolder.ApplicationData` (#188) * xamarin/xamarin-android-tools@0d55472 LEGO: Merge pull request 187 * xamarin/xamarin-android-tools@6946512 Juno: check in to juno/hb_befb220e-87ce-47e9-a9e6-10ea592b2337_20220729154833425. (#186) * xamarin/xamarin-android-tools@6e3433a Juno: check in to juno/hb_befb220e-87ce-47e9-a9e6-10ea592b2337_20220729025332507. (#185) * xamarin/xamarin-android-tools@73c4388 [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-33 (#184) * xamarin/xamarin-android-tools@da3653e [Xamarin.Android.Tools.AndroidSdk] Add API-33 to KnownVersions * xamarin/xamarin-android-tools@327d433 [ci] Run OneLocBuild on a schedule (#180) * xamarin/xamarin-android-tools@8ab60e4 [ci] Use latest macOS and Windows images (#181) * xamarin/xamarin-android-tools@4dd3292 LEGO: Merge pull request 182 * xamarin/xamarin-android-tools@56b61f1 [Localization] Add OneLocBuild job (#175) * xamarin/xamarin-android-tools@14076a6 [Xamarin.Android.Tools.AndroidSdk] Add API-32 to KnownVersions
2022-08-26 22:18:30 +03:00
<LibZipSharpVersion>2.0.7</LibZipSharpVersion>
[ci] Split up signing for files to be notarized (#7321) The signing steps that run on macOS to prepare a PKG for notarization have been slow and are frequently failing. Attempt to fix this by splitting up the files we send to ESRP on macOS into multiple batches to hopefully put less pressure on the service. A `signClassicPkgContent` parameter has also been added to allow us to skip these steps while testing, or when building .NET release branches if needed. MicroBuild tooling has also been updated to the latest versions.
2022-08-31 01:05:33 +03:00
<MicroBuildCoreVersion>1.0.0</MicroBuildCoreVersion>
Bump to dotnet/installer/main@3b43390 (#6131) Changes: https://github.com/dotnet/installer/compare/cc10fae...3b43390 Changes: https://github.com/mono/linker/compare/6eae019...0cb9250 Changes: https://github.com/dotnet/runtime/compare/d019e70...cf52b7e Updates: * Microsoft.Dotnet.Sdk.Internal: from 6.0.100-rc.1.21376.3 to 6.0.100-rc.1.21379.2 * Microsoft.NET.ILLink.Tasks: from 6.0.100-preview.6.21370.1 to 6.0.100-preview.6.21378.1 * Microsoft.NETCore.App.Ref: from 6.0.0-rc.1.21374.7 to 6.0.0-rc.1.21378.2 Bump to Mono.Cecil 0.11.4. Hopefully fixes a [build break][0]: CSC : error CS1705: Assembly 'illink' with identity 'illink, Version=6.0.100.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' uses 'Mono.Cecil, Version=0.11.4.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e' which has a higher version than referenced assembly 'Mono.Cecil' with identity 'Mono.Cecil, Version=0.11.3.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e' Bump `$(MonoCecilVersion)` to compensate? Note: an actual fix very likely requires a Java.Interop bump, as Java.Interop references Cecil 0.11.3 (same as the error message) while `$(MonoCecilVersion)` is 0.11.2 (not present in the error). [0]: https://github.com/xamarin/xamarin-android/pull/6131#pullrequestreview-716413727 Context: https://github.com/xamarin/xamarin-android/pull/6131#pullrequestreview-716413727 Context: fcb9ea3 Changes: http://github.com/xamarin/Java.Interop/compare/4fb7c147f8c6eb9bf94d9bfb8305c7d2a7a9fb33...dd1ef455ee4fbfa7e17f34c51cbe2ef24459e2e6 * xamarin/java.interop@dd1ef45: Bump to mono/linker@b888d67 Mono.Cecil 0.11.4 (#861) Commit fcb9ea3 didn't fix the build breakage. Bump to xamarin/java.interop@dd1ef45 and set `$(_XamarinAndroidCecilVersion)`, which will override the Mono.Cecil NuGet package version within the Java.Interop build. This will hopefully ensure/allow everything to now use Cecil 0.11.4. TODO: This Quick-And-Dirty approach hardcodes `$(_XamarinAndroidCecilVersion)`=0.11.4, meaning we now have two different properties for the same thing: Directory.Build.props: <MonoCecilVersion>0.11.4</MonoCecilVersion> build-tools/scripts/Configuration.Java.Interop.Override.props: <_XamarinAndroidCecilVersion>0.11.4</_XamarinAndroidCecilVersion> This is "undesirable". Is there a way to update `xaprepare` so that we can generate `external/Java.Interop/Configuration.Override.props` so that `$(_XamarinAndroidCecilVersion)`=`$(MonoCecilVersion)`? (Assuming that this approach even works…) Co-authored-by: Jonathan Pryor <jonpryor@vt.edu>
2021-07-30 16:09:50 +03:00
<MonoCecilVersion>0.11.4</MonoCecilVersion>
Bump to JamesNK/Newtonsoft.Json@ae9fe44e [13.0.1] (#6090) Changes: https://github.com/JamesNK/Newtonsoft.Json/compare/12.0.3...13.0.1 * JamesNK/Newtonsoft.Json@ae9fe44e: Remove compiler package and update sourcelink (#2498) * JamesNK/Newtonsoft.Json@8ef66218: Remove prerelease for 13.0.1 * JamesNK/Newtonsoft.Json@11331f50: Update SDK to 5.0.200 (#2495) * JamesNK/Newtonsoft.Json@c7e8abc0: Update to 13.0.1-beta2 * JamesNK/Newtonsoft.Json@1745d7c1: Fix JTokenWriter when writing comment to an object (#2493) * JamesNK/Newtonsoft.Json@583eb120: Fix missing error when deserializing JToken with a contract type mismatch (#2494) * JamesNK/Newtonsoft.Json@b6dc05be: Change MaxDepth default to 64 (#2473) * JamesNK/Newtonsoft.Json@15525f1c: Fix JsonWriter.WriteToken to allow null with string token (#2472) * JamesNK/Newtonsoft.Json@926d2f0f: Enable embed untracked sources (#2471) * JamesNK/Newtonsoft.Json@0a56633b: Fixes #2372 - variable typos (#2465) * JamesNK/Newtonsoft.Json@5a35c77d: Update version to 13.0.1 (#2463) * JamesNK/Newtonsoft.Json@7e77bbe1: Change JsonReader and JsonSerializer default max depth to 128 (#2462) * JamesNK/Newtonsoft.Json@42139ea6: Add JsonSelectSettings and regex timeout * JamesNK/Newtonsoft.Json@95a6eb3a: jpath regex timeout support added for a single regex expression, global umbrella for all regex calls, and support for allowing regex calls to get compiled if necessary * JamesNK/Newtonsoft.Json@1403f5d3: Fix serializing nullable struct dictionaries (#2452) * JamesNK/Newtonsoft.Json@60be32f4: Use naming strategy when deserializing dictionary enum keys (#2448) * JamesNK/Newtonsoft.Json@ff5ffb28: Copy annotations when cloning elements (#2442) * JamesNK/Newtonsoft.Json@0cf47a46: Missing nullability annotation (#2438) * JamesNK/Newtonsoft.Json@6795ca55: Fixed tests to work in Moscow, Russia UTC+3 timezone. (#2416) * JamesNK/Newtonsoft.Json@c918ca86: Code Typo Fix: Universial => Universal (#2383) * JamesNK/Newtonsoft.Json@c298f3d6: Fix typo in SerializeTypeNameHandling sample (#2428) * JamesNK/Newtonsoft.Json@a222c8b6: Update to net50 and fix warnings (#2424) * JamesNK/Newtonsoft.Json@666d9760: Fix wrong define is used in StringUtils.ToLower() (#2304) * JamesNK/Newtonsoft.Json@a31156e9: Update NullValueHandlingIgnore.aml (#2226) * JamesNK/Newtonsoft.Json@936acbf6: Update version to 13.0.1-beta and remove portable builds (#2228) * JamesNK/Newtonsoft.Json@9be95e0f: Do not treat ignored field as missing member when deserializing from overriden json constructor (#2224) The `PackagingTest.NetStandardReferenceTest()` test is updated, as the list of implicitly referenced assemblies changed: * `Microsoft.CSharp.dll` is no longer referenced * `System.Data.dll` is now referenced. It appears that the primary cause of this change is that with `Newtonsoft.Json` 12.0.3, the .NET Standard 1.3-profile assemblies were included into the app, while with 13.0.1, the .NET Standard-2.0 profile assemblies are instead used.
2021-07-16 18:50:45 +03:00
<NewtonsoftJsonPackageVersion>13.0.1</NewtonsoftJsonPackageVersion>
[Xamarin.Android.Build.Tasks] Use Microsoft.Android.Build.BaseTasks (#5464) Context: https://github.com/xamarin/xamarin-android-tools/pull/101 Context: https://github.com/xamarin/monodroid/pull/1145 We would like to eventually remove the dependency that xamarin/monodroid has on xamarin/xamarin-android. As a first step towards this effort, shared MSBuild code is being moved to xamarin/xamarin-android-tools. `Xamarin.Android.Build.Tasks` has been updated to use the new shared `Microsoft.Android.Build.BaseTasks` sources. All of the files that were moved to xamarin/xamarin-android-tools have been deleted. The inverted monodroid build has been replaced with the new monodroid build system, see https://github.com/xamarin/monodroid/pull/1145 for more context. The one build task test that was still being ran from the xamarin/monodroid repo has been moved into `DebuggingTasksTests.cs`, which is conditionally included in `Xamarin.Android.Build.Tests`. Tests associated with the build task source that was moved to xamarin/xamarin-android-tools have also been moved to a new `Microsoft.Android.Build.BaseTasks-Tests` assembly in that repo.
2021-02-05 21:43:04 +03:00
<NuGetApiPackageVersion>5.4.0</NuGetApiPackageVersion>
[tmt] Add TypeMap dumper utility (#5541) Add a new utility which can dump the typemap information found within native libraries and `.apk` files. The new utility is accessible within the build tree as `bin/$(Configuration)/bin/tmt`, e.g. `bin/Debug/bin/tmt`. This utility is *not* part of the installer; it's currently intended primarily for internal use. See `tools/tmt/README.md` for usage details.
2021-02-10 23:28:09 +03:00
<LZ4PackageVersion>1.1.11</LZ4PackageVersion>
[build] Update to Mono.Options 6.12.0.148, add .pdb to installer (#6407) Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1421424/ Changes: https://github.com/xamarin/java.interop/compare/d1d64c10281eaa895fa415dfcafb8ed716a0db3c...974ad32ee415af01556867f21add270e21bc241e * xamarin/java.interop@974ad32e: [build] Copy Mono.Options.pdb to output directory (#896) A recent update to `Mono.Options.dll` (presumably commit ad5f6e85) has caused a symbol check failure in our latest VS insertion. We can fix this by updating one of the tools projects that references this package to copy `Mono.Options.pdb` to the Output Directory. Once the file is in the right output path, update the installers so that `Mono.Options.pdb` is included in the Xamarin.Android installers.
2021-10-21 05:11:42 +03:00
<MonoOptionsVersion>6.12.0.148</MonoOptionsVersion>
[xabuild] update binding redirects for MSBuild 17.3 (#7273) `xabuild Xamarin.Android-Tests.sln` was failing with: MSBUILD : error MSB1025: An internal failure occurred while running MSBuild. System.IO.FileLoadException: Could not load file or assembly 'System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' at Microsoft.Build.Shared.FileUtilities.LooksLikeUnixFilePath(String value, String baseDirectory) at Microsoft.Build.CommandLine.MSBuildApp.GatherCommandLineSwitches(List`1 commandLineArgs, CommandLineSwitches commandLineSwitches, String commandLine) at Microsoft.Build.CommandLine.MSBuildApp.GatherAllSwitches(String commandLine, CommandLineSwitches& switchesFromAutoResponseFile, CommandLineSwitches& switchesNotFromAutoResponseFile) at Microsoft.Build.CommandLine.MSBuildApp.Execute(String commandLine) This appears to be happening on Windows build machines running Visual Studio 2022 17.3 and MSBuild 17.3. I did an audit comparing xabuild's `App.config` file with: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe.config We needed to update specifically to: * System.Memory 4.5.5 * System.Collections.Immutable 6.0.0 * System.Runtime.CompilerServices.Unsafe 6.0.0 Note that in some cases the NuGet package version doesn't match the assembly version. After these changes, I can build `xabuild` locally with MSBuild 17.3, and then also build Xamarin.Android projects.
2022-08-17 23:47:52 +03:00
<SystemCollectionsImmutableVersion>6.0.0</SystemCollectionsImmutableVersion>
<SystemRuntimeCompilerServicesUnsafeVersion>6.0.0</SystemRuntimeCompilerServicesUnsafeVersion>
[Xamarin.Android.Build.Tasks] Don't package empty AOT-d DSOs (#6477) Fixes: https://github.com/xamarin/xamarin-android/issues/3932 Profiled AOT tends to produce a number of "empty" `.so` shared libraries because the profile names only a handful of types from a handful of assemblies and the AOT compiler in Mono currently doesn't support not outputting the `.so` in such cases. This has the unfortunate effect that an application may have a large number of such empty `.so` libraries and each of them will have to be opened and loaded before Mono can determine that there's no code in them and the JIT has to compile the requested types and methods. Loading every `.so` takes a non-zero amount of time, especially if the shared libraries aren't unpacked to the filesystem. I've seen times between 10-30ms to load a single shared library, which can add up to a non-trivial amount of time wasted loading empty libraries. This commit adds code to examine and ignore such `.so` files which don't include any executable code. The checks are crafted so that only AOT-d libraries are considered for rejection. The check is kinda/sorta like: o=`llvm-readelf -a path/to/lib.so` if echo $o | grep mono_aot_file_info && : lib has 'mono_aot_file_info' symbol echo $o | grep FUNC ; then : lib contains executable code echo "AOT'd file contains code" fi If the `mono_aot_file_info` symbol isn't present, the `.so` is always included. Time savings are around 3ms for a Classic Xamarin.Android app and around 10ms for a sample MAUI app on the Pixel 3 XL phone. In the latter case 49 shared libraries out of 120 total are rejected and not packaged, contributing to (small, each empty DSO is between 7 and 25k) space savings in the `.apk` in addition to slightly better startup performance. Update the `<ApkDiffCheckRegression/>` so that the size difference threshold for reporting issues with `.apk` diffs is 48KB, not 50KB, as a 50KB threshold meant that no changes were reported for `Xamarin.Forms_Performance_Integration-Signed-Release-Profiled-Aot.apkdesc`. Reducing the threshold to 48KB allowed us to see the result of this optimization.
2021-11-22 19:07:01 +03:00
<ELFSharpVersion>2.13.1</ELFSharpVersion>
Bump to mono/api-doc-tools/main@97c1778d [mdoc 5.8.9.2] (#7175) Context: https://github.com/mono/api-doc-tools/commit/039a03016419e9e9234611ba143a75400ec6325d Context: https://github.com/mono/api-doc-tools/pull/638 Changes: https://github.com/mono/api-doc-tools/compare/mdoc-5.8.5...mdoc-5.8.9.2 Updates [mdoc][0] to the latest release, and add a parameter to `azure-pipelines-apidocs.yaml` to allow any version of mdoc to be used when generating docs. [0]: https://www.nuget.org/packages/mdoc
2022-07-18 20:10:33 +03:00
<MdocPackageVersion Condition=" '$(MdocPackageVersion)' == '' ">5.8.9.2</MdocPackageVersion>
[ci] Enable signing for .NET 6 artifacts (#5529) Context: https://github.com/xamarin/yaml-templates/tree/564100f2aa923ee4db4b69cc45a622822643309b/sign-artifacts Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/650/Enabling-Signing-in-Your-Projects The structure of our YAML pipeline has been updated to enable signing for all relevant .NET 6 artifacts. The new pipeline hierarchy is described below: mac_build ... sign nupkgs create net6 .pkg download signed .nupkgs push signed .nupkgs to feed harden/sign mach-o binaries create .pkg sign .pkg notarize .pkg publish .pkg create net6 .msi download signed .nupkgs download notarized .pkg create and sign .msi upload .msi and .pkg to blob storage The `dotnet_installers` stage now starts with a templated job which will sign all `.nupkg` files created by the `mac_build` stage. These signed packages are then downloaded by a new macOS job that will push them to a feed and use them to create, sign, and notarize the .NET 6 `.pkg` file. Finally, the job which previously created our .NET 6 `.msi` has been updated to wait for the result of the .NET 6 `.pkg` creation job. This job will now consume the signed `.nupkg` files to produce a signed `.msi`, and upload both the signed `.pkg` and `.msi` files to blob storage. None of the `MicroBuild` tasks/targets will run during local builds, so we do not need to worry about additional environment provisioning when creating these installers locally. In order to test locally, the MicroBuild signing NuGet needs to be installed locally and either the `$(MicroBuildOverridePluginDirectory)` or `$(MicroBuildPluginDirectory)` properties must be set and point to the folder where the signing NuGet was installed. See the ["Enabling signing in your projects" wiki][0] above for more information. The new `SignList.xml` file is used by the `.nupkg` signing job. The content of this file controls which certs are used to sign which files. Anything that was signed through an alternate source should be added to the `@(Skip)` ItemGroup. Any third party file that needs signing should be added to the `@(ThirdParty)` ItemGroup. [0]: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/650/Enabling-Signing-in-Your-Projects
2021-01-27 00:22:33 +03:00
</PropertyGroup>
[build] Set up new Windows lane using `dotnet build` (#5482) Create a new Windows build lane that Prepares and builds `Xamarin.Android.sln` using `dotnet build` instead of using the .NET Framework. Currently this is only implemented for Windows. Run `dotnet xaprepare.dll` instead of `xaprepare.exe`. Remove `tools/xabuild/xabuild.csproj` from `Xamarin.Android.sln` and instead build it as a separate step using .Net Framework/Mono. This project has issues due to its extensive "creative" use of MSBuild. Some fixups to `create-vsix`: by default .Net Core only serializes string resources. Added MSBuild prop and needed NuGet to support other resource types. By default .Net Core contains fewer encoding standards. Add `System.Text.Encoding.CodePages` to `xaprepare` to add support for `iso-8859-4`, needed by `Kajabity`. Future work needed: - This is everything needed to build `Xamarin.Android.sln`, but not everything needed by CI. We still call: - `msbuild create-vsix` - `msbuild Xamarin.Android.sln /t:PackDotNet` (requires .NET 6) - `msbuild xabuild` - `xabuild Xamarin.Android-Tests.sln` - Some executables that we build and run like `api-xml-adjuster` are still running their `.exe` form. - macOS support. macOS still uses `mono` and not `dotnet`.
2021-02-17 20:01:02 +03:00
<!-- Properties to help us run managed assemblies on various runtimes.
Ex:
* Mono: mono xaprepare.exe
* Windows .NET: xaprepare.exe
* dotnet: dotnet xaprepare.dll
-->
<PropertyGroup Condition=" '$(MSBuildRuntimeType)' != 'Core' ">
<ManagedToolInvocationRuntime>$(Runtime) </ManagedToolInvocationRuntime>
<ManagedToolInvocationExtension>.exe</ManagedToolInvocationExtension>
</PropertyGroup>
<PropertyGroup Condition=" '$(MSBuildRuntimeType)' == 'Core' ">
<ManagedToolInvocationRuntime>dotnet </ManagedToolInvocationRuntime>
<ManagedToolInvocationExtension>.dll</ManagedToolInvocationExtension>
</PropertyGroup>
[build] Update Bootstrap task projects to short-form style (#3928) Updates `build-tools/Xamarin.Android.BootstrapTasks`, `build-tools/xa-prep-tasks`, and other related or dependent projects to SDK-style short form style projects targeting `netstandard2.0`. A new top level `Directory.Build.props` file has been added to contain common properties that will be automatically imported everywhere. In the longer term, we can look to migrate content from `Configuration.props` to this file. New `$(PrepTasksAssembly)` and `$(BootstrapTasksAssembly)` MSBuild Properties have been added so that fewer changes will be required when updating the output path of these assemblies in the future. All files which reference these assemblies have been updated to use these new properties. `RunTests.targets` and `RunApkTests.targets` have been updated to explicitly import `Directory.Build.props` as we pass these files directly to `msbuild` invocations in certain cases. (`Directory.Build.props` was not being implicitly imported in those cases; I believe that implicit import only occurs when building a `.sln` or `.csproj`.) Finally, `$(CopyLocalLockFileAssemblies)`=True has been moved to `Directory.Build.props` file so that all of our short-form style projects will inherit this behavior.
2020-02-12 02:19:54 +03:00
</Project>