Skip to content

CONFIG: Fix Linux native library PackagePath in LibPostalNet - #101

Merged
cjdutoit merged 1 commit into
mainfrom
users/perirrs/fix-libpostalnet-linux-packagepath
Aug 24, 2026
Merged

CONFIG: Fix Linux native library PackagePath in LibPostalNet#101
cjdutoit merged 1 commit into
mainfrom
users/perirrs/fix-libpostalnet-linux-packagepath

Conversation

@perirrs

@perirrs perirrs commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Fixes AB#29898 (follow-up to #84)

Problem

libpostal-1.so was being packed to a PackagePath ending in .dll:

<Content Include="libpostal-1.so" PackagePath="contentFiles\linux_x86_64\libpostal-1.dll" />

Because the source and destination extensions do not match, NuGet treats the destination as a directory rather than a file rename. The resulting package contained:

contentFiles/linux_x86_64/libpostal-1.dll/libpostal-1.so

NHSISL.LibPostalNet.targets resolves LinuxNativeFiles from contentFiles/linux_x86_64/libpostal-1.so. That item therefore matched nothing on Linux, the Copy task silently copied zero files, and the native library never reached the output directory — a DllNotFoundException at runtime for Linux consumers.

Fix

One line — the destination now matches the source extension.

Verification

Rebuilt the package and inspected it:

Path in package
Before contentFiles/linux_x86_64/libpostal-1.dll/libpostal-1.so
After contentFiles/linux_x86_64/libpostal-1.so

This now matches what the targets file expects. NHSISL.LibPostalClient.csproj already used the correct pattern.

Why now

NHSISL.LibPostalNet became packable and part of the solution in #84 but has not yet been published to nuget.org. Fixing the layout before the first release avoids it becoming a breaking change for consumers later.

🤖 Generated with Claude Code

The libpostal-1.so content item was being packed to a PackagePath
ending in .dll. Because the source and destination extensions did not
match, NuGet treated the destination as a directory rather than a file
rename, producing:

  contentFiles/linux_x86_64/libpostal-1.dll/libpostal-1.so

NHSISL.LibPostalNet.targets resolves LinuxNativeFiles from
contentFiles/linux_x86_64/libpostal-1.so, so on Linux the item matched
nothing, the Copy task silently copied no files, and the native library
never reached the output directory.

Verified the rebuilt package now places the file at
contentFiles/linux_x86_64/libpostal-1.so.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Copilot AI lite review requested due to automatic review settings August 24, 2026 12:08

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR corrects the NuGet package layout for the Linux native libpostal-1.so in NHSISL.LibPostalNet so that the packed path matches what NHSISL.LibPostalNet.targets consumes at build/publish time, preventing missing native library copies for Linux consumers.

Changes:

  • Fix PackagePath for libpostal-1.so to end in .so (not .dll) so NuGet treats it as a file path, not a directory.
  • Align packaged Linux native file location with NHSISL.LibPostalNet.targets’s LinuxNativeFiles include path.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@cjdutoit
cjdutoit merged commit 76fba0f into main Aug 24, 2026
9 checks passed
@cjdutoit
cjdutoit deleted the users/perirrs/fix-libpostalnet-linux-packagepath branch August 24, 2026 13:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants