System.DirectoryServices.Protocols.LdapConnection fails to find the new version of the LDAP library on Alpine linux 3.20

[horato]

Description

It's basically the same issue as #69456 except on alpine linux. Libldap 2.6.8 was released.
https://pkgs.alpinelinux.org/packages?name=libldap&branch=v3.20&repo=&arch=x86_64&origin=&flagged=&maintainer=

.net standard 2.0 library using nuget System.DirectoryServices.Protocols 8.0.0, hosted via net8.0 app in alpine linux.

Reproduction Steps

See #69456
Except the app is run in alpine docker instead of ubuntu
FROM mcr.microsoft.com/dotnet/runtime:8.0-alpine AS base

Expected behavior

See #69456

Actual behavior

See #69456

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

[steveharter]

Need a more flexible approach for version matching; see

runtime/src/libraries/Common/src/Interop/Linux/OpenLdap/Interop.Ldap.cs

Lines 74 to 84 in 81efcad

	// Register callback that tries to load other libraries when the default library "libldap-2.5.so.0" not found
	AssemblyLoadContext.GetLoadContext(currentAssembly).ResolvingUnmanagedDll += (assembly, ldapName) =>
	{
	if (assembly != currentAssembly || ldapName != Libraries.OpenLdap)
	{
	return IntPtr.Zero;
	}
	// Try load next (libldap-2.6.so.0) or previous (libldap-2.4.so.2) versions
	if (NativeLibrary.TryLoad("libldap-2.6.so.0", out IntPtr handle) ||
	NativeLibrary.TryLoad("libldap-2.4.so.2", out handle))

[horato]

OpenLDAP seems to be creating symlinks in /usr/lib/libldap.so, maybe those could be used?
https://github.com/flamencist/ldap4net/blob/master/linux.md

[steveharter]

OpenLDAP seems to be creating symlinks in /usr/lib/libldap.so, maybe those could be used?

Yes thanks that should work.

Pending testing on Ubuntu+ we could just use liblber.so.2 and not check liblber.so and perhaps not even check the libldap-* meaning change this to liblber.so.2 and remove the ResolvingUnmanagedDll callback approach.

In the meantime, I assume the workaround is to add your own symlink to an older version.

[steveharter]

@joperezr before I go further, do you recall any investigation into using the libldap.so.2 symlink instead of hard-coding the symlink that contains the major.minor version such as libldap-2.6.so.0?

It seems OpenLDAP client creates this (and liblber.so.2) in /lib or /usr/lib which will reference the latest version in the same drectory.

[joperezr]

Not that I'm aware of. Originally we opted to use major minor because that hadn't change in 10+ years, and there weren't new versions available. That said, after we shipped then a new version was released, which is when @buyaa-n looked into the assembly loading hook that you pointed out IIRC.

[joperezr]

And of course, if we don't know what type of changes may be introduced in a library, using major.minor guarantees that the shape of the api as well as the behavior will match expectations, as opposed to referencing a floating version-less one.

[buyaa-n]

When adding ResolvingUnmanagedDll callback we did not know that OpenLDAP client creates libldap.so.2 symlink, do not see any official doc about it. Looks it is not guaranteed to be created, so I would add it as another option within the callback instead of removing the ResolvingUnmanagedDll handler completely