Repository navigation
Package downgrades for Xamarin.AndroidX.Lifecycle.Common.Java8 #4095
Description
Package
Sentry
.NET Flavor
.NET
.NET Version
9.0.202
OS
Android
OS Version
No response
Development Environment
Rider 2024 (MacOS)
SDK Version
5.5.1
Self-Hosted Sentry Version
No response
Workload Versions
Installed Workload Id Manifest Version Installation Source
android 35.0.39/9.0.100 SDK 9.0.200
ios 18.2.9180/9.0.100 SDK 9.0.200
maccatalyst 18.2.9180/9.0.100 SDK 9.0.200
macos 15.1.9163/9.0.100 SDK 9.0.200
maui 9.0.20/9.0.100 SDK 9.0.200
tvos 18.2.9173/9.0.100 SDK 9.0.200
wasm-tools 9.0.2/9.0.100 SDK 9.0.200
UseSentry or SentrySdk.Init call
NA
Steps to Reproduce
- Have a dependency on Xamarin.AndroidX.Lifecycle.Common 2.8.7.2
- Update Sentry to 5.5.1
<PackageVersion Include="Xamarin.AndroidX.Lifecycle.Common" Version="2.8.7.2" />
<PackageVersion Include="Sentry" Version="5.5.1" />Expected Result
Sentry should upgrade nicely
Actual Result
When upgrading from 5.5.0 to 5.5.1 we now get package downgrade errors:
D:\a\1\s\src\Sentry.Mobile\Sentry.Mobile.csproj : error NU1608: Warning As Error: Detected package version outside of dependency constraint: Xamarin.AndroidX.Lifecycle.Process 2.8.5.1 requires Xamarin.AndroidX.Lifecycle.Runtime (>= 2.8.5.1 && < 2.8.6) but version Xamarin.AndroidX.Lifecycle.Runtime 2.8.7.2 was resolved. [D:\a\1\s\KioskMDM.sln]
D:\a\1\s\src\Sentry.Mobile\Sentry.Mobile.csproj : error NU1107: Version conflict detected for Xamarin.AndroidX.Lifecycle.Common. Install/reference Xamarin.AndroidX.Lifecycle.Common 2.8.7.2 directly to project Sentry.Mobile to resolve this issue. [D:\a\1\s\KioskMDM.sln]
D:\a\1\s\src\Sentry.Mobile\Sentry.Mobile.csproj : error NU1107: Sentry.Mobile -> Microsoft.Maui.Essentials 9.0.50 -> Xamarin.AndroidX.Browser 1.8.0.8 -> Xamarin.AndroidX.Core 1.15.0.2 -> Xamarin.AndroidX.Lifecycle.Runtime 2.8.7.2 -> Xamarin.AndroidX.Lifecycle.Common (>= 2.8.7.2 && < 2.8.8) [D:\a\1\s\KioskMDM.sln]
D:\a\1\s\src\Sentry.Mobile\Sentry.Mobile.csproj : error NU1107: Sentry.Mobile -> Sentry.Extensions.Logging 5.5.1 -> Sentry 5.5.1 -> Sentry.Bindings.Android 5.5.1 -> Xamarin.AndroidX.Lifecycle.Common.Java8 2.8.5.1 -> Xamarin.AndroidX.Lifecycle.Common (>= 2.8.5.1 && < 2.8.6). [D:\a\1\s\KioskMDM.sln]
Failed to restore D:\a\1\s\src\Sentry.Mobile\Sentry.Mobile.csproj (in 7.12 sec).
Adding Xamarin.AndroidX.Lifecycle.Common directly to the Sentry.Mobile project does not solve the issue.
The dependency on Xamarin.AndroidX.Lifecycle.Common.Java8 seems to be new, and is very restrictive of which version of Lifecycle packages you can install.
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
- StatusShow more project fieldsNo status
Activity
jamescrosswell commentedon Apr 9, 2025
We include these dependencies here in
Sentry.Bindings.Android.csproj:sentry-dotnet/src/Sentry.Bindings.Android/Sentry.Bindings.Android.csproj
Lines 43 to 52 in a888dde
They are dependencies of the Java SDK that we reference:
sentry-dotnet/src/Sentry.Bindings.Android/Sentry.Bindings.Android.csproj
Lines 62 to 68 in a888dde
We should probably be allowing a range there, so something like:
jamescrosswell commentedon Apr 9, 2025
Hm, tricky. We don't seem to be able to do that:
Cheesebaron commentedon Apr 9, 2025
So I have these dependencies which have their respective dependencies:
The App I run also uses bits of Xamarin.AndroidX.Lifecycle. So that is why I am using this specific version.
jamescrosswell commentedon Apr 9, 2025
OK. It looks like a classic diamond dependency problem:
I wonder if it's possible for you to tell NuGet to use newer versions of the dependencies Sentry needs by including these in your csproj explicitly (rather than rely on NuGet's transitive dependency resolution). For example:
That's all of Sentry's dependencies, but with versions that would (hopefully) be compatible with
Microsoft.Maui.Essentials 9.0.50.MAUIoxo commentedon Apr 11, 2025
I also face this issue after upgrading to .NET MAUI 9.0.60.
Compile works with Sentry 5.5.0 and not with 5.5.1.
To be honest, did not expect this with an update to a newer patch version 5.5.x
48 remaining items
albyrock87 commentedon May 13, 2025
Heads up, a new upgrade has just landed on
mainpointing to2.8.7.3.It will be included in SR8.
dotnet/maui@f65f1ea
On the FAQ I think it's better to suggest a separate
ItemGrouplike this:bruno-garcia commentedon May 14, 2025
Is there a way we can work with the MAUI team to improve this situation? (sorry, drive by feedback as I’m not well educated in the details).
@Redth might have ideas
aritchie commentedon May 14, 2025
@bruno-garcia my PR takes care of the issue. The goal is for our library to go back as far as it can. MAUI will pull us forward on whatever version they want to use. The reason this PR hasn't gone through was due to the issues we kept having with CI
jamescrosswell commentedon May 16, 2025
Unfortunately that PR doesn't resolve the issue.
Other than statically linking dependencies (not an option when the dependencies are the Android APIs), diamond dependency issues are a pretty tough nut to crack.
The only solution I can think of would be if the entire .NET community aligned on the versions of dependencies that they would target... implicitly that's what we do every year to build support for the .NET runtime. MS make some breaking changes in .NET 9, for example, and everyone's SDK and applications get updated (making all the necessary breaking changes) and we're happy with that until the next set of breaking changes that require another major version release.
@Redth the situation could be alleviated if MS locked the versions of Java depdendencies that are used by the .NET workloads (and by stuff like the Community Toolkit) with every new major release of .NET.... that way all of the SDKs and applications in the .NET community could align on the versions of those dependencies as at the time of the release of the TFM they're building to and everything would keep ticking over until the next major .NET release.
At the moment, that's not happening. New point releases of MAUI workloads are bumping versions of the Java dependencies. In some situations work arounds might be available. We're fortunate enough at Sentry that we're not heavily using the Android APIs and so we only have a minimum version constraint (no upper bound)... I think those workarounds should always work where our SDK specifically is concerned then. But I don't think there are any guarantees those workarounds will work in all situations
jamescrosswell commentedon May 20, 2025
PR to add troubleshooting documentation here, for anyone who is interested:
@albyrock87 regarding your comment, the specific solution will depend on the other NuGets people are referencing. It wasn't really possible to provide code that people could copy/paste then... instead I'm hoping the article explains things well enough that people will be able to find a solution that works in their specific circumstances.
Android dotnet package version outside of dependency constraint (#13763)
Android dotnet package version outside of dependency constraint (#13763)