[NET8] Fix assembly count when satellite assemblies are present #8821
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Context: e6002f8 The `release/8.0.1xx` versioning will be stable with .NET 8 GA. We will start out with 34.0.1, and each commit increments by 1. We have to reset `$(AndroidPackVersion)` so it will "reset" the commit distance.
Authenticode signing attempts started failing recently with:
ERROR: 'xsign' is misspelled or not recognized by the system.
Updating to Python 3 is the suggested fix for this issue.
Changes: xamarin/monodroid@c360498...e57630b * [build] set $(DisableTransitiveFrameworkReferenceDownloads)=true * [tools/msbuild] bump to JDK 17.0.8 for InstallAndroidDependencies * [msbuild] Add new Fast Deployment tool xamarin.cp
Changes: dotnet/installer@e1fd7d9...2ff90f1 Updates: * Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rc.2.23468.1 to 8.0.100-rtm.23475.14 * Microsoft.NETCore.App.Ref: from 8.0.0-rc.2.23466.4 to 8.0.0-rtm.23472.12 * Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport: from 8.0.0-rc.2.23463.1 to 8.0.0-rtm.23470.1 * Microsoft.NET.ILLink.Tasks: from 8.0.0-rc.2.23466.4 to 8.0.0-rtm.23472.12 * Microsoft.DotNet.Cecil: from 0.11.4-alpha.23461.1 to 0.11.4-alpha.23468.2 Other changes: * Feeds for dotnet/runtime 7.0.12 * Feeds for dotnet/runtime 6.0.23 * Version bands for Mono and emsdk workloads are `8.0.100-rtm` Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
Context: #8360 MSBuild tests that use `net7.0-android` `TargetFrameworks` can fail on release branches with: (Restore target) -> error NU1102: Unable to find package Microsoft.AspNetCore.App.Ref with version (= 7.0.12) error NU1102: - Found 1621 version(s) in dotnet7 [ Nearest version: 7.0.0-rtm.22513.3 ] error NU1102: - Found 1537 version(s) in dotnet8 [ Nearest version: 8.0.0-alpha.1.22416.11 ] error NU1102: - Found 87 version(s) in testsource1 [ Nearest version: 8.0.0-preview.1.23112.2 ] error NU1102: - Found 87 version(s) in dotnet-public [ Nearest version: 8.0.0-preview.1.23112.2 ] error NU1102: - Found 0 version(s) in darc-pub-dotnet-emsdk-9506882 error NU1102: - Found 0 version(s) in darc-pub-dotnet-runtime-26e0f82 error NU1102: - Found 0 version(s) in darc-pub-dotnet-runtime-301ba1e error NU1102: - Found 0 version(s) in dotnet-eng error NU1102: - Found 0 version(s) in dotnet8-transport error NU1102: - Found 0 version(s) in xamarin.android util 0 Warning(s) 1 Error(s) To solve this, we can set `$(DisableTransitiveFrameworkReferenceDownloads)` as we did in 2320e20 so it doesn't try to restore ASP.NET or Windows Desktop packs. The MSBuild integration tests have their own `Directory.Build.props`, so this seems like a reasonable place to set this value.
Changes: dotnet/installer@2ff90f1...da40dcb Changes: dotnet/runtime@e95228d...a3d5300 Changes: dotnet/emsdk@446eeb3...41db232 Updates: * Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rtm.23475.14 to 8.0.100-rtm.23477.4 * Microsoft.NETCore.App.Ref: from 8.0.0-rtm.23472.12 to 8.0.0-rtm.23475.7 * Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport: from 8.0.0-rtm.23470.1 to 8.0.0-rtm.23473.1 * Microsoft.NET.ILLink.Tasks: from 8.0.0-rtm.23472.12 to 8.0.0-rtm.23475.7
…T 8 (#8375) Fixes: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1837913 Context: dc3ccf2 Testing on a DevBox with only the .NET 8 RC 1 SDK and `dotnet workload install maui`: > dotnet new android > dotnet build -t:InstallAndroidDependencies -p:AndroidSdkDirectory=C:\tools\android-sdk -p:JavaSdkDirectory=C:\tools\jdk -bl Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.Debugging.targets(110,2): error XA5300: The Android SDK directory could not be found. Check that the Android SDK Manager in Visual Studio shows a valid installation. To use a custom SDK path for a command line build, set the 'AndroidSdkDirectory' MSBuild property to the custom path. Ok, that's completely broken... So let's add `-c Release`, as this target is related to Fast Deployment: Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.targets(664,2): error : Could not locate Java 6 or 7 SDK. I tested .NET 7 and it worked fine?!? It turns out to be due to an additional `_ResolveMonoAndroidSdks` target running in .NET 8 that *doesn't* run in .NET 7: https://github.com/xamarin/xamarin-android/blob/547a157a7aeae930e4fc6092636fa20771ff1ef6/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.BuildOrder.targets#L181 This was introduced in dc3ccf2, but I don't think it was needed. The `GetAndroidDependencies` target doesn't run during a normal build, so it doesn't seem like `$(GetAndroidDependenciesDependsOn)` should need to run anything extra either. Update `$(GetAndroidDependenciesDependsOn)` so that the `_ResolveMonoAndroidSdks` target is no longer executed. With this change in place, `InstallAndroidDependencies` works on my DevBox, and I'm also able to build apps in `Debug` and `Release` mode.
Changes: dotnet/installer@da40dcb...4e39632 Changes: dotnet/runtime@a3d5300...885100b Changes: dotnet/emsdk@41db232...0a2aae8 Updates: * Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rtm.23477.4 to 8.0.100-rtm.23479.1 * Microsoft.NETCore.App.Ref: from 8.0.0-rtm.23475.7 to 8.0.0-rtm.23477.9 * Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport: from 8.0.0-rtm.23473.1 to 8.0.0-rtm.23475.3 * Microsoft.NET.ILLink.Tasks: from 8.0.0-rtm.23475.7 to 8.0.0-rtm.23477.9
Changes: dotnet/installer@4e39632...6dae849 Updates: * Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rtm.23479.1 to 8.0.100-rtm.23479.3
Changes: dotnet/installer@6dae849...471a817 Changes: dotnet/runtime@885100b...b20f704 changes: dotnet/emsdk@0a2aae8...ae4eaab Changes: dotnet/cecil@89be445...13d6536 Updates: * Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rtm.23479.3 to 8.0.100-rtm.23502.10 * Microsoft.NETCore.App.Ref: from 8.0.0-rtm.23477.9 to 8.0.0-rtm.23478.17 * Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport: from 8.0.0-rtm.23475.3 to 8.0.0-rtm.23477.1 * Microsoft.NET.ILLink.Tasks: from 8.0.0-rtm.23477.9 to 8.0.0-rtm.23478.17 * Microsoft.DotNet.Cecil: from 0.11.4-alpha.23468.2 to 0.11.4-alpha.23476.1
Package update attempts started failing recently on our Linux lane:
Setting up grub-efi-amd64-signed (1.187.6~20.04.1+2.06-2ubuntu14.4) ...
mount: /var/lib/grub/esp: special device /dev/disk/by-id/scsi-14d5346542020202075f68e4df928b946a6a92fab5bc044c1-part15 does not exist.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 32
Our base Linux OS image is updated regularly by 1ES, so we shouldn't
need to update during every CI run.
Changes: dotnet/installer@471a817...77a7628 Changes: dotnet/runtime@b20f704...a84f8ff Changes: dotnet/cecil@13d6536...64a8874 Updates: * Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rtm.23502.10 to 8.0.100-rtm.23505.1 * Microsoft.NETCore.App.Ref: from 8.0.0-rtm.23478.17 to 8.0.0-rtm.23503.15 * Microsoft.NET.ILLink.Tasks: from 8.0.0-rtm.23478.17 to 8.0.0-rtm.23503.15 * Microsoft.DotNet.Cecil: from 0.11.4-alpha.23476.1 to 0.11.4-alpha.23502.1
Changes: dotnet/installer@77a7628...0ffc9fd Changes: dotnet/runtime@a84f8ff...22b8a56 Updates: * Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rtm.23505.1 to 8.0.100-rtm.23506.1 * Microsoft.NETCore.App.Ref: from 8.0.0-rtm.23503.15 to 8.0.0-rtm.23504.8 * Microsoft.NET.ILLink.Tasks: from 8.0.0-rtm.23503.15 to 8.0.0-rtm.23504.8
Changes: dotnet/runtime@a84f8ff...b17a34c This a manual bump, Maestro can update for us after this is merged. * Removed `CoherentParentDependency="Microsoft.Dotnet.Sdk.Internal"` * `darc update-dependencies --id 195870` Using the build number from: * https://maestro-prod.westus2.cloudapp.azure.com/3073/https:%2F%2Fgithub.com%2Fdotnet%2Fruntime/latest/graph
Updates xaprepare to install the `sources-34_r01` Android SDK package, allowing our API docs generation tasks to use the latest sources.
…8392) Context: #8387 Context: 2c6f5cd Context: f7ea4a3 Context: d794534 Update the value for `$(AndroidManifestMerger)` (f7ea4a3) to `manifestmerger.jar`. This allows users to make use of the new features like `@(AndroidManifestOverlay)` (d794534) out of the box. The old system is still available, users will need to add the following to their csproj: <AndroidManifestMerger>legacy</AndroidManifestMerger> AndroidX has been building with `$(AndroidManifestMerger)`=manifestmerger.jar for [over three years][0]. [0]: dotnet/android-libraries@c6c0e50
…OverrideInheritance). (#8393) Context: dotnet/java-interop@8e63cc8 Context: dotnet/java-interop@d0231c5 dotnet/java-interop@d0231c5c updated generator output so that `[Obsolete]` would automagically "flow" to derived types and method overrides, so that [warning CS0672][0] would not be emitted. Before dotnet/java-interop@d0231c5c, we would emit: public class Context { [Obsolete] public virtual void SetWallpaper () { … } } public class ContextWrapper : Context { [ObsoletedOSPlatform ("android23.0")] public override void SetWallpaper () { … } } `ContextWrapper.SetWallpaper()` would elicit a CS0672 warning: warning CS0672: Member 'ContextWrapper.SetWallpaper()' overrides obsolete member 'Context.SetWallpaper()'. Add the Obsolete attribute to 'ContextWrapper.SetWallpaper()' With dotnet/java-interop@d0231c5c, we now emit the following, which no longer emits CS0672: public class Context { [Obsolete] public virtual void SetWallpaper () { … } } public class ContextWrapper : Context { [Obsolete] public override void SetWallpaper () { … } } While we feel that this is a nice improvement, this broke some customers who didn't want their bindings to automatically gain `[Obsolete]` "just because" they were overriding `[Obsolete]` types or members. In dotnet/java-interop@8e63cc8d, we added the ability to globally *opt-out* of this new behavior by using `generator --lang-features=do-not-fix-obsolete-overrides`. Add a new `$(AndroidEnableObsoleteOverrideInheritance)` MSBuild property. When False, this adds `generator --lang-features=do-not-fix-obsolete-overrides`, preventing the automatic CS0672 fix behavior. By default `$(AndroidEnableObsoleteOverrideInheritance)` is True. [0]: https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0672
Changes: dotnet/java-interop@75d8221...d7f41c4 * dotnet/java-interop@d7f41c4e: [build] introduce `xamarin-android-tools.override.props` (dotnet/java-interop#1148) * dotnet/java-interop@9ac0dd4c: Bump to xamarin/xamarin-android-tools/main@8a971d9 (dotnet/java-interop#1146) Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [external/Java.Interop](https://github.com/xamarin/java.interop) from `d7f41c4` to `8e63cc8`. - [Commits](dotnet/java-interop@d7f41c4...8e63cc8) --- updated-dependencies: - dependency-name: external/Java.Interop dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Changes: dotnet/java-interop@8e63cc8...ed63d89 * [generator] restore `[RegisterAttribute]` for *Implementor types Other changes: * Added test to verify `Lmono/android/view/View_OnClickListenerImplementor;` exists after a build using `AndroidLinkMode=r8`. dotnet/java-interop#1149
Changes: dotnet/installer@0ffc9fd...dfe59b6 Updates: Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rtm.23506.1 to 8.0.100-rtm.23512.1
Changes: dotnet/runtime@b17a34c...256bf22 Updates: * Microsoft.NET.ILLink.Tasks: from 8.0.0-rtm.23506.12 to 8.0.0-rtm.23511.16 * Microsoft.NETCore.App.Ref: from 8.0.0-rtm.23506.12 to 8.0.0-rtm.23511.16 Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
…8376) Context: 628d6cb Context: dc3ccf2 We have a very odd situation with the [`Xamarin.CommunityToolkit.MauiCompat` NuGet package][0]: The NuGet package ships with a file `.net/__res_name_case_map.txt` (628d6cb) in `Xamarin.CommunityToolkit.MauiCompat.aar` which contains the case map changes for the `@(AndroidResource)` items. The purpose of this file is to allow the user to use PascalCase (or any case) names in C# code, while the Android Resource compilation is left as all lowercase. This is because Android requires that file-backed resource names consist of only lowercase letters. The contents of this file includes: Resources/Layout/CameraFragment.axml;layout/camerafragment.xml which tells us that the Android `R.layout.camerafragment` resource id should be "bound" as `Resouce.Layout.CameraFragment`, which allows [`CameraFragment.android.cs` to build][1]: public override AView? OnCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) => inflater.Inflate(Resource.Layout.CameraFragment, null); However, when we look at the IL that comes from the NuGet package we see the only lowercase `camerafragment`: ikdasm ~/.nuget/packages/xamarin.communitytoolkit.mauicompat/2.0.2-preview1013/lib/net6.0-android31.0/Xamarin.CommunityToolkit.MauiCompat.dll| grep Layout::camerafragment … IL_0131: stsfld int32 Xamarin.CommunityToolkit.MauiCompat.Resource/Layout::camerafragment … IL_0001: ldsfld int32 Xamarin.CommunityToolkit.MauiCompat.Resource/Layout::camerafragment For some reason as part of the XamarinCommunityToolkit build [the following script][2] was run on the code: sed -i '' 's/MauiCompat.Resource.Layout.CameraFragment/MauiCompat.Resource.Layout.camerafragment/g' ./src/CommunityToolkit/Xamarin.CommunityToolkit.MauiCompat/**/CameraFragment.android.cs This changes `Resource.Layout.CameraFragment` to `Resource.Layout.camerafragment`, apparently because *something* is renaming [`CameraFragment.axml`][3] to `camerafragment.axml` *after* `__res_name_case_map.txt` is generated, but before `CameraFragment.android.cs` is compiled. The NuGet still includes the `.aar` with the case map changes, which are now inconsistent with the assembly contents. I'm not sure why XamarinCommunityToolkit does all this. The result of the above XamarinCommunityToolkit build and packaging behavior is that it interacts badly with the new net8.0-android Resource Designer Assembly (dc3ccf2) work, with a build-time error: error XA8000: Could not find Android Resource ‘@layout/camerafragment’. Please update @(AndroidResource) to add the missing resource. This is because we are looking for the lowercase version of the resource in the Designer assembly property list, but because of the remap file we only know about the PascalCase version. As a workaround, fallback to a *case-insensitive* resource name lookup if a case-sensitive lookup fails. [0]: https://www.nuget.org/packages/Xamarin.CommunityToolkit.MauiCompat/ [1]: https://github.com/xamarin/XamarinCommunityToolkit/blob/5a6062f3c3543acda3c36ca4683cd8fc7fe86ba7/src/CommunityToolkit/Xamarin.CommunityToolkit/Views/CameraView/Android/CameraFragment.android.cs#L129 [2]: https://github.com/xamarin/XamarinCommunityToolkit/blob/5a6062f3c3543acda3c36ca4683cd8fc7fe86ba7/MauiCompat.sh#L561 [3]: https://github.com/xamarin/XamarinCommunityToolkit/blob/5a6062f3c3543acda3c36ca4683cd8fc7fe86ba7/src/CommunityToolkit/Xamarin.CommunityToolkit/Resources/Layout/CameraFragment.axml
) Fixes: #8409 Context: #8272 The [`//service/@android:foregroundServiceType`][0] attribute can be generated based on the value of the `Android.App.ServiceAttribute.ForegroundServiceType` property: [Service(ForegroundServiceType=ForegroundService.TypeCamera)] partial class MyService : Service { } which will result in an `AndroidManifest.xml` fragment such as: <service android:foregroundServiceType="camera" android:name="crc64….MyService" /> However, a number of `ForegroundService` enum values have been added without corresponding updates to `ServiceAttribute` XML generation. Consequently, using "recently added" values such as `ForegroundService.TypeHealth` would result in those values *not* being added to the generated `//service/@android:foregroundServiceType`. Update `ManifestDocumentElement.cs` to update `ToString(ForegroundService)` so that all current `ForegroundService` enum values are supported. This will allow: [Service(ForegroundServiceType= ForegroundService.TypeCamera | // previously supported ForegroundService.TypeMicrophone)] // new hawtness partial class MyService : Service { } to properly emit: <service android:foregroundServiceType="camera|microphone" android:name="crc64….MyService" /> [0]: https://developer.android.com/guide/topics/manifest/service-element#foregroundservicetype
) Fixes: #7692 When `.java` files are part of a project through `@(AndroidJavaSource)`, it would be nice if the *bindings* for those Java types would be available through IDE IntelliSense/code completion. Update the `AddBindingsToCompile` target so that it includes all `$(IntermediateOutputPath)generated\**\*.cs` files into the design- time build. Additionally, fix an issue where if you remove the libraries the generated files are not removed. Finally, move the Layout CodeBehind generated files to their own `$(IntermediateOutputPath)codebehind` directory. This is to keep the code behind and generated code separate, as it makes it easier to update and clean up if one or the other changes. When all the files are in the same location we might end up deleting files we otherwise need during an update process, slowing down the build.
Changes: dotnet/installer@dfe59b6...c65382f Updates: Microsoft.Dotnet.Sdk.Internal: from 8.0.100-rtm.23512.1 to 8.0.100-rtm.23513.4 Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
Changes: dotnet/runtime@256bf22...60b77a6 Updates: * Microsoft.NET.ILLink.Tasks: from 8.0.0-rtm.23511.16 to 8.0.0-rtm.23513.17 * Microsoft.NETCore.App.Ref: from 8.0.0-rtm.23511.16 to 8.0.0-rtm.23513.17 Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
Fixes: dotnet/maui#17265 Context: dc3ccf2 Context: https://github.com/Zack-G-I-T/SfListView.Net8Bug/tree/ecb25af3329391858d1d64c4875ca58771e2b66c Commit dc3ccf2 completely reworked how Android Resources work, moving from a `$(RootNamespace).Resource` type which contained fields (which needed to be updated at runtime across numerous assemblies) to a "`_Microsoft.Android.Resource.Designer` reference assembly" which contained *methods* for each Resource id. To maintain backward compatibility, pre-.NET 8 assemblies were rewritten so that instead of accessing fields: ldsfld int32 $(RootNamespace).Resource/Layout::Toolbar they became method calls: call int32 [_Microsoft.Android.Resource.Designer]_Microsoft.Android.Resource.Designer.Resource/Layout::get_Toolbar() Unfortunately we encountered a missing corner case: the previous fixup logic only operated on assemblies that themselves contained a `$(RootNamespace).Resource` type, which in turn (generally) required that the assembly be built from a project that had `@(AndroidResource)` items. In dotnet/maui#17265 and Zack-G-I-T/SfListView.Net8Bug, we encountered an assembly that: 1. Did *not* contain a `Resource` type, and 2. Used Resource ids from other assemblies, and 3. Was a .NET 7 assembly, so it and its dependencies were all using the .NET 7 field-based Resource approach. Setup: * `Ako` and `Bko` are net7.0-android projects which contain an `@(AndroidResource)` * `RefsLibs` is a net7.0-android project which references `Ako` and `Bko`, and uses the Resource values from them. * `App` is a net8.0-android project which references `RefsLibs`. "Repro" setup: dotnet new androidlib -n Ako # Set `$(TargetFramework)`=net7.0-android # Add Ako/Resources/values/strings.xml with String resource ako_name dotnet new androidlib -n Bko # Set `$(TargetFramework)`=net7.0-android # Add Bko/Resources/values/strings.xml with String resource bko_name dotnet new androidlib -n RefsLibs # Set `$(TargetFramework)`=net7.0-android # Add ProjectReference to ..\Ako\Ako.csproj, ..\Bko\Bko.csproj # Update `RefsLibs\Class1.cs` to use Ako.Resource.String.ako_name, Bko.Resource.String.bko_name dotnet new android -n App # *Remains* `$(TargetFramework)`=net8.0-android # Add ProjectReference to ..\RefsLibs\RefsLibs.csproj The punch: dotnet build App/App.csproj -p:Configuration=Release This fails to build with .NET 8 RC1: ILLink : error IL1013: Error processing '/Users/jon/Downloads/dotnet-sdk-8.0.100-rc.1.23455.8-osx-x64/packs/Microsoft.Android.Sdk.Darwin/34.0.0-rc.1.432/targets/../PreserveLists/Mono.Android.xml'. Fatal error in IL Linker Unhandled exception. Mono.Linker.LinkerFatalErrorException: ILLink: error IL1013: Error processing '/Users/jon/Downloads/dotnet-sdk-8.0.100-rc.1.23455.8-osx-x64/packs/Microsoft.Android.Sdk.Darwin/34.0.0-rc.1.432/targets/../PreserveLists/Mono.Android.xml'. ---> System.ArgumentNullException: Value cannot be null. (Parameter 'key') at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior) at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value) … …/build/Microsoft.NET.ILLink.targets(87,5): error NETSDK1144: Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false. "Interestingly", it *succeeds* with .NET 8 RC2 (no build errors). Regardless, with both .NET 8 RC1 and RC2, the app is *broken*: % dotnet tool install --global dotnet-ilverify % $HOME/.dotnet/tools/ilverify App/obj/Release/net8.0-android/android-arm/linked/RefsLibs.dll \ --tokens --system-module System.Private.CoreLib \ -r 'App/obj/Release/net8.0-android/android-arm/linked/*.dll' [IL]: Error [ClassLoadGeneral]: […/App/obj/Release/net8.0-android/android-arm/linked/RefsLibs.dll : RefsLibs.Class1::.ctor()] Failed to load type 'String' from assembly 'Ako, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' [IL]: Error [CallCtor]: […/App/obj/Release/net8.0-android/android-arm/linked/RefsLibs.dll : RefsLibs.Resource::.ctor()][offset 0x00000001] call to .ctor only allowed to initialize this pointer from within a .ctor. Try newobj. [IL]: Error [ThisUninitReturn]: […/App/obj/Release/net8.0-android/android-arm/linked/RefsLibs.dll : RefsLibs.Resource::.ctor()][offset 0x00000006] Return from .ctor when this is uninitialized. 3 Error(s) Verifying …/App/obj/Release/net8.0-android/android-arm/linked/RefsLibs.dll If you disassemble `RefsLibs.dll`, you find that it's using `ldsfld`, not `call`: % ikdasm App/obj/Release/net8.0-android/android-arm/linked/RefsLibs.dll … .method public hidebysig specialname rtspecialname instance void .ctor() cil managed { // Code size 29 (0x1d) .maxstack 8 IL_0000: ldarg.0 IL_0001: ldsfld int32 [Ako]Ako.Resource/String::ako_name IL_0006: stfld int32 RefsLibs.Class1::a IL_000b: ldarg.0 IL_000c: ldsfld int32 [Bko]Bko.Resource/String::bko_name IL_0011: stfld int32 RefsLibs.Class1::b IL_0016: ldarg.0 IL_0017: call instance void [System.Private.CoreLib]System.Object::.ctor() IL_001c: ret } // end of method Class1::.ctor If you attempt to run the .NET 8 RC2 build, it fails at runtime: I MonoDroid: android.runtime.JavaProxyThrowable: [System.TypeLoadException]: Arg_TypeLoadException I MonoDroid: at App.MainActivity.OnCreate(Unknown Source:0) I MonoDroid: at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_(Unknown Source:0) The problem is that `RefsLibs.dll` isn't being fixed up as part of dc3ccf2, because it doesn't contain any `@(AndroidResource)` values or an `[assembly: ResourceDesigner]` custom attribute. `RefsLibs.dll` is "free floating", with nothing to indicate that it needs to be updated. Fix this scenario by updating `LinkDesignerBase` to "sanity check" all "Resource-like" member references which cannot be resolved. Consider: % monodis --memberref RefsLibs/bin/Release/net7.0-android/RefsLibs.dll … 18: TypeRef[23] ako_name Resolved: [Ako]Ako.Resource/String.ako_name Signature: int32 19: TypeRef[25] bko_name Resolved: [Bko]Bko.Resource/String.bko_name Signature: int32 These are field references. In the context of .NET 8/dc3ccf28, these fields *will not exist*; they cannot be resolved. `LinkDesignerBase` will check the member references table of *all* assemblies included in the app, and if any member references contain a declaring type which contains `.Resource/` *and* that member reference cannot be resolved, we will assume that it is an `@(AndroidReference)` and replace it with a `call` to the appropriate method. With the fix in place, `ilverify` no longer reports `Error [ClassLoadGeneral]`, and `ikdasm` shows: % ikdasm App/obj/Release/net8.0-android/android-arm/linked/RefsLibs.dll … .method public hidebysig specialname rtspecialname instance void .ctor() cil managed { // Code size 29 (0x1d) .maxstack 8 IL_0000: ldarg.0 IL_0001: call int32 [_Microsoft.Android.Resource.Designer]_Microsoft.Android.Resource.Designer.Resource/String::get_ako_name() IL_0006: stfld int32 RefsLibs.Class1::a IL_000b: ldarg.0 IL_000c: call int32 [_Microsoft.Android.Resource.Designer]_Microsoft.Android.Resource.Designer.Resource/String::get_bko_name() IL_0011: stfld int32 RefsLibs.Class1::b IL_0016: ldarg.0 IL_0017: call instance void [System.Private.CoreLib]System.Object::.ctor() IL_001c: ret } // end of method Class1::.ctor Note that the .NET 7 `ldsfld` has been replaced with `call`. Co-authored-by: Dean Ellis <dellis1972@googlemail.com>
Changes: dotnet/java-interop@ed63d89...3c83179 * dotnet/java-interop@3c831796: [class-parse] Add Kotlin metadata to `-dump`. (dotnet/java-interop#1150) Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
First, I had to update the URL we test, because it was down: https://httpstat.us/200 Instead, I used: https://httpbin.org/status/200 Next, after reviewing the latest methods in the profile, I noticed a lot of timezone logic was completely removed. This might be related to different cookies returns from the new URL, not sure. I added a `DateTime.Now` call to `CommonMethods.cs`, to ensure the timezone logic is in the AOT profile. Testing a `dotnet new android` app on a Pixel 5, an average of 10 runs of the "displayed time`: Average(ms): 179.1 Std Err(ms): 2.53179778023443 Std Dev(ms): 8.00624756049924
Fixes: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1918037 Context: https://github.com/dotnet/templating/wiki/Reference-for-template.json Context: https://github.com/dotnet/templating/wiki/Post-Action-Registry#open-a-file-in-the-editor Within Visual Studio, if you: 1. Create a new .NET MAUI or .NET Android app, then 2. Go to the Solution Explorer, then 3. Right-click a folder, then click Add > New Item > Android, then 4. Double-click the **Android Activity** template. The expected result is that a new Android Activity based on the Android Activity template will be added to your solution *and opened in the editor*. Instead, a new Android Activity is added, but it is *not* opened. Update the `.template.config/template.json` files to contain a `postActions` section with a `openInEditor` id. This *should* cause Visual Studio to open the new files within the editor.
Changes: dotnet/runtime@59edaad...a6e4834 Updates: * Microsoft.NET.ILLink: from 8.0.0-rtm.23524.7 to 8.0.1-servicing.23579.14 * Microsoft.NET.ILLink.Tasks: from 8.0.0 to 8.0.1 * Microsoft.NETCore.App.Ref: from 8.0.0 to 8.0.1 * Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: from 8.0.0 to 8.0.1 Other changes: * Keep System.IO.Hashing on 8.0.0, there is no 8.0.1 version yet Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
Fixes: dotnet/runtime#95506 In Release configuration the `X509ExtendedTrustManagerInvoker` class is trimmed and so the `trustManager is IX509TrustManager tm` pattern matching doesn't work. This PR addresses the problem in two ways: * an internal X509 trust manager is now required - it can't silently work with a null internal trust manager anymore * `[DynamicDependency]` attribute to prevent trimming of the invoker classes for the `IX509TrustManager` interface and for the `X509ExtendedTrustManager` abstract class
Follow-up to #8594 to fix dotnet/runtime#95506 on Android API 21-23
LEGO: Merge pull request 8642
Context: https://aka.ms/onelocbuild Context: https://aka.ms/AllAboutLoc * Build definition ID 17928: Build ID 8930705
…oid.txt` (#8641) We are seeing numerous test failures because of this warning. warning XA4304: ProGuard configuration file 'C:\Android\android-sdk\tools\proguard\proguard-android.txt' was not found. This is because the `proguard-android.txt` file no longer ships with the Android SDK. We should check this file exists before adding it to the list of `@(_ProguardConfiguration)` files. This way if a user still does have it, it will be included.
…droid.Support (#8648) Context: 2f19238 Commit 2f19238 introduces a new XA1039 error when the Android Support libraries are referenced by a .NET 9 project. For .NET 8, partially backport 2f19238 to emit an XA1039 *warning* when the Android Support libraries are referenced by a .NET 8 project. Also introduce a new `$(_AndroidIgnoreAndroidSupportWarning)` MSBuild property as an escape hatch if someone needs to completely disable the warning: <_AndroidIgnoreAndroidSupportWarning>true</_AndroidIgnoreAndroidSupportWarning> .NET 9 will not honor or support `$(_AndroidIgnoreAndroidSupportWarning)`.
…s `repackaged.jar` (#8664) Context: https://maven.google.com/androidx/emoji2/emoji2/1.4.0/emoji2-1.4.0.aar Context: https://maven.google.com/androidx/health/connect/connect-client/1.1.0-alpha07/connect-client-1.1.0-alpha07.aar When using the two AARs linked above, you get the build error: Xamarin.Android.Common.targets(845,3): error XA1014: JAR library references with identical file names but different contents were found: repackaged.jar. Please remove any conflicting libraries from EmbeddedJar, InputJar and AndroidJavaLibrary. They both contain `libs/repackaged.jar`, which I'm not able to find any information about. I can reproduce this problem in an MSBuild test. Unfortunately, the only way to workaround the error message is to: * Unzip the `.aar` * Rename `libs/repackaged.jar` to `libs/repackaged-emoji2-1.4.0.jar`, for example * Re-zip the `.aar` a9ca3d4 had a similar problem with `r-classes.jar`. Let's expand upon this change by introducing a private item group: <ItemGroup> <_AndroidExcludedDuplicateJavaLibraries Include="classes.jar" /> <_AndroidExcludedDuplicateJavaLibraries Include="r-classes.jar" /> <_AndroidExcludedDuplicateJavaLibraries Include="repackaged.jar" /> </ItemGroup> So if this occurs in the future, we can add future files to this list without rebuilding the Android workload.
We currently do not allow installation of the `android` workload on linux-arm64, but suspect that it may work for some customers. Given that our [runtime dependencies][0] are now available for linux-arm64, we can stop restricting installation to solicit feedback. [0]: https://github.com/dotnet/runtime/blob/087ca4662309f3db40b3096cbf89853d9c292e16/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.net8.Manifest/WorkloadManifest.json.in#L44
* Localized file check-in by OneLocBuild Task (#8652) Context: https://aka.ms/onelocbuild Context: https://aka.ms/AllAboutLoc Build definition ID 17928: Build ID 8944839 * LEGO: Merge pull request 8656 LEGO: Merge pull request 8656 * Localized file check-in by OneLocBuild Task (#8657) Context: https://aka.ms/onelocbuild Context: https://aka.ms/AllAboutLoc Build definition ID 17928: Build ID 8952275 * LEGO: Merge pull request 8665 LEGO: Merge pull request 8665 * Localized file check-in by OneLocBuild Task (#8668) Context: https://aka.ms/onelocbuild Context: https://aka.ms/AllAboutLoc Build definition ID 17928: Build ID 8968258 --------- Co-authored-by: VS MobileTools Engineering Service 2 <vsmobiletoolsengsvc2@microsoft.com> Co-authored-by: CSIGS@microsoft.com <csigs@users.noreply.github.com>
Context: dotnet/runtime@a6e4834...c987e4f Context: dotnet/emsdk@201f4da...2fc2ffd Updates: * Microsoft.NET.ILLink: from 8.0.1-servicing.23579.14 to 8.0.2-servicing.24067.8 * Microsoft.NET.ILLink.Tasks: from 8.0.1 to 8.0.2 * Microsoft.NETCore.App.Ref: from 8.0.1 to 8.0.2 * Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: from 8.0.1 to 8.0.2 Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
…rror (#8640) Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1922983 Our error matching in Aapt2.cs did not include a new error message which has been introduced. As a result we got a APT2000 error instead of an actual error message which we get for other errors.
Changes: xamarin/monodroid@7b6faa3...7edfb4a * [ci] Fix monodroid component inclusion * [release/8.0.1xx] Bump xamarin-android and yaml ref * [release/8.0.1xx] Bump to xamarin/androidtools@6993959a
Changes: dotnet/android-libzipsharp@3.0.0...3.1.1 * dotnet/android-libzipsharp@7abbbf4: Bump Version to 3.1.1 (dotnet/android-libzipsharp#136) * dotnet/android-libzipsharp@ca8a64a: [CMake] Add /PROFILE to MSVC link flags (dotnet/android-libzipsharp#134) * dotnet/android-libzipsharp@22957e4: Bump to microsoft/vcpkg@c8696863d3 (dotnet/android-libzipsharp#133) * dotnet/android-libzipsharp@ed2ccd5: A round of library version updates (dotnet/android-libzipsharp#131) Various compiler and linker flag changes to assist APIScan.
Changes: dotnet/runtime@c987e4f...62304a6 Changes: dotnet/emsdk@2fc2ffd...9a29abd Updates: * Microsoft.NET.ILLink: from 8.0.2-servicing.24067.8 to 8.0.3-servicing.24114.15 * Microsoft.NET.ILLink.Tasks: from 8.0.2 to 8.0.3 * Microsoft.NETCore.App.Ref: from 8.0.2 to 8.0.3 * Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: from 8.0.2 to 8.0.3
Fixes: dotnet/maui#20752 Context: d1ba2cc Context: dotnet/android-tools@34e98e2 Context: #8746 `dotnet build` (.NET Core) ignores assembly versions. `msbuild.exe` (.NET Framework) does not. Enter d1ba2cc, which updates the `libZipSharp.dll` assembly version from 3.0.0.0 to 3.1.1.0. However, this change only impacted `Xamarin.Android.Build.Tasks.dll`: % monodis --assemblyref bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/34.99.0/tools/Xamarin.Android.Build.Tasks.dll … 11: Version=3.1.1.0 Name=libZipSharp Flags=0x00000000 It did *not* impact `Microsoft.Android.Build.BaseTasks.dll`, as it is built by `external/xamarin-android-tools` and was using a `@(PackageReference)` for libZipSharp 3.0.0: % monodis --assemblyref bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/34.99.0/tools/Microsoft.Android.Build.BaseTasks.dll … 5: Version=3.0.0.0 Name=libZipSharp Flags=0x00000000 The resulting NuGet package only contains *one* `libZipSharp.dll`, the 3.1.1.0 version (what `Xamarin.Android.Build.Tasks.dll` refs). On PR builds and CI, everything was fine, because all the tests we have use `dotnet build`, and .NET Core ignores assembly versions. However, if you use *`msbuild.exe`* to invoke the tasks within `Microsoft.Android.Build.BaseTasks.dll`, things fail: XARLP7028 System.IO.FileNotFoundException: Could not load file or assembly 'libZipSharp, Version=3.0.0.0, Culture=neutral, PublicKeyToken=276db85bc4e20efc' or one of its dependencies. The system cannot find the file specified.File name: 'libZipSharp, Version=3.0.0.0, Culture=neutral, PublicKeyToken=276db85bc4e20efc' at Xamarin.Android.Tasks.ResolveLibraryProjectImports.Extract(IDictionary`2 jars, ICollection`1 resolvedResourceDirectories, ICollection`1 resolvedAssetDirectories, ICollection`1 resolvedEnvironments, ICollection`1 proguardConfigFiles) at Xamarin.Android.Tasks.ResolveLibraryProjectImports.RunTask() at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 25 Fix this by adding an `external/xamarin-android-tools.override.props` file (dotnet/android-tools@34e98e2b) which imports `Directory.Build.props`, which causes `$(LibZipSharpVersion)` to be set so that the xamarin-android-tools build uses values provided by xamarin-android. TODO: #8746 adds a unit test for the "build with `msbuild.exe`" scenario.
Fixes: #8779 Updates all NuGet packages other than Microsoft.Android.Sdk to include the MIT license at the root of the repo. The license file name and contents have also been updated to improve consistency with other dotnet repos.
Changes: dotnet/java-interop@bec0326...3c5cf34 * dotnet/java-interop@3c5cf34b: [generator] Extend `skipInvokerMethods` support to interfaces. (dotnet/java-interop#1203)
Removes the conditional compiler directives used to swap between `.NET` and `MonoAndroid`. These are no longer needed in main as `.NET` is the only supported target.
…build.props` (#8717) Fixes: https://developercommunity.visualstudio.com/t/Visual-Studio-2022-Community-1785-ver/10577484 Related: #8662 I found the following build performance issue using a .NET Android project template inside VS Windows: 1. Create a new .NET Android project 2. Open some `AndroidResource` `.xml` file in the Android designer 3. *Every* incremental build appears to rebuild everything! `obj\Debug\net8.0-android\build.props` appears to be changing between builds with the change: ```diff --androidsupportedabis=armeabi-v7a;arm64-v8a;x86;x86_64 ++androidsupportedabis=arm64-v8a ``` I narrowed this down to the designer running two targets, `PrepareResources;_GenerateCompileInputs`: https://github.com/xamarin/UITools/blob/7b167eae94ae018ab19344d6bfb45a925415e2a7/src/Xamarin.Designer.Android/Xamarin.AndroidDesigner/MSBuildConstants.cs#L32 In this example: * The designer does *not* mark the build as a "design-time build" with `-p:DesignTimeBuild=true`. This would have used a design-time `build.props`. * The designer does *not* pass in the selected Android device. This code is *ancient*, so I suspect this has just always been an issue? Perhaps, it only occurs in .NET 6+ projects and not Xamarin.Android? Because `$(AndroidSupportedAbis)` is not a "supported" thing in .NET 6+, let's just remove it? Removing `$(AndroidSupportedAbis)` from this file manually does fix the problem for me locally: C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.52\tools\Xamarin.Android.Common.targets There is also a *second* `adb.props` file that triggers a subset of things to rebuild if the selected Android device changes: <WriteLinesToFile File="$(_AdbPropertiesCache)" Lines="AdbTarget=$(AdbTarget);AdbOptions=$(AdbOptions)" Usage of the new property, `$(RuntimeIdentifier)`, also changes `$(IntermediateOutputPath)`, so I feel like we shouldn't need this value in `build.props` in a .NET 6+ world.
Fixes: #8740 There is a race condition in `AndroidMessageHandler` (see #8740 (comment) for more information). The solution is fairly simple: we should determine the decompression strategy only during the setup, when `AutomaticDecompression` is set. We don't need to do any more work during the request. To prevent changing the decompression strategy while there are requests mid-flight, the setter will only accept values until the first request is sent. This is exactly what the `SocketsHttpHandler` does. I didn't want to touch any code unrelated to the race condition in this PR so if we want to prevent other properties from being mutated while HTTP requests are being sent, we should do it in a follow-up PR.
Context: #8790 The old method of satellite assembly counting relied on the `RelativePath` MSBuild item metadata, which appears to have gone missing somewhere in .NET8+. Update the code to check for presence of the following metadata, in order given, to determine assembly's culture, if any: * `Culture` * `RelativePath` * `DestinationSubDirectory` Failure to count satellite assemblies can, and sometimes will, result in a segfault since we generate a number of native code arrays based on the assembly count and the runtime assumes that what the build told it is true.
Contributor
Author
|
Doh, wrong base branch |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: #8790
The old method of satellite assembly counting relied on the
RelativePathMSBuild item metadata, which appears to have gonemissing somewhere in .NET8+. Update the code to check for presence
of the following metadata, in order given, to determine assembly's
culture, if any:
CultureRelativePathDestinationSubDirectoryFailure to count satellite assemblies can, and sometimes will,
result in a segfault since we generate a number of native code
arrays based on the assembly count and the runtime assumes that
what the build told it is true.