Skip to content

[Breaking change]: .NET Linux applications do not look in netcoredeps sub-directory for native libraries #45777

Closed
@elinor-fung

Description

@elinor-fung

Description

To support third-party dependencies in self-contained Linux applications, .NET applications had their RPATH set to $ORIGIN/netcoredeps such that they would look for libraries used by the runtime in that location. This also had the side effect that all native library loads (that is, including p/invokes defined by the user) would also look in the netcoredeps subdirectory.

This behaviour was an artifact of the complicated dependencies of .NET at the time - a situation which has since improved. In .NET 8 and later, .NET linux applications no longer look in the netcoredeps subdirectory when loading native libraries.

See dotnet/runtime#114393

Version

.NET 8

Previous behavior

.NET Linux applications looked in a netcoredeps subdirectory next to the application executable when loading native libraries.

New behavior

.NET Linux applications no longer look in a netcoredeps subdirectory next to the application executable when loading native libraries.

Type of breaking change

  • Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
  • Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
  • Behavioral change: Existing binaries might behave differently at run time.

Reason for change

The netcoredeps behaviour was introduced to handle complicated .NET dependencies on third-party libraries - which should not be an issue in recent versions of .NET. It was never intended to be used for other native libraries.

It affected more than its intend use case, that use case itself had no support story, and the mechanism it used is not the modern recommended path for ELF platforms.

Recommended action

If users were using this mechanism for p/invokes, DllImportResolver' or ResolvingUnmanagedDll` should be used instead for custom resolution.

If users want an RPATH set in their deployment, they can modify the ELF file explicitly.

Feature area

Interop

Affected APIs

DllImport
NativeLibrary.Load


Associated WorkItem - 419669

Metadata

Metadata

Assignees

Labels

📌 seQUESTeredIdentifies that an issue has been imported into Quest.breaking-changeIndicates a .NET Core breaking change

Type

No type

Projects

Status

✅ Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions