Nerdbank.gitversioning: Pop!_OS 20.04 not supported

[bradwilson]

I haven't tried it with straight Ubuntu 20.04 yet; this is a newly paved machine with Pop!_OS 20.04.

/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018: The "Nerdbank.GitVersioning.Tasks.GetBuildVersion" task failed unexpectedly. [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018: System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:  ---> System.PlatformNotSupportedException: pop.20.04-x64 [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at Nerdbank.GitVersioning.RuntimeIdMap.GetNativeLibraryDirectoryName(String runtimeIdentifier) [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at Nerdbank.GitVersioning.GitLoaderContext.GetNativeLibraryDirectory() [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at Nerdbank.GitVersioning.GitLoaderContext.LoadUnmanagedDll(String unmanagedDllName) [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at System.Runtime.Loader.AssemblyLoadContext.ResolveUnmanagedDll(String unmanagedDllName, IntPtr gchManagedAssemblyLoadContext) [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at LibGit2Sharp.Core.NativeMethods.git_libgit2_init() [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at LibGit2Sharp.Core.NativeMethods.InitializeNativeLibrary() [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at LibGit2Sharp.Core.NativeMethods..cctor() [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    --- End of inner exception stack trace --- [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at LibGit2Sharp.Core.NativeMethods.git_libgit2_opts(Int32 option, UInt32 level, String path) [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at LibGit2Sharp.Core.Proxy.git_libgit2_opts_set_search_path(ConfigurationLevel level, String path) [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at LibGit2Sharp.GlobalSettings.SetConfigSearchPaths(ConfigurationLevel level, String[] paths) [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at Nerdbank.GitVersioning.GitExtensions.OpenGitRepo(String pathUnderGitRepo, Boolean useDefaultConfigSearchPaths) [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at Nerdbank.GitVersioning.VersionOracle.Create(String projectDirectory, String gitRepoDirectory, ICloudBuild cloudBuild, Nullable`1 overrideBuildNumberOffset, String projectPathRelativeToGitRepoRoot) [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.1.91/build/Nerdbank.GitVersioning.targets(71,5): error MSB4018:    at Nerdbank.GitVersioning.Tasks.GetBuildVersion.ExecuteInner() [/home/bradwilson/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]

Note that unlike the recent 18.04 issue, this is not related to Omnisharp; this fails with dotnet build as well.

[AArnott]

Looking... Ubuntu-20 works fine. Is Pop OS based on Ubuntu 20?
I hope Pop_OS has a docker image I can test within.

[AArnott]

I can't find a docker image. What's the quickest way to repro this problem?

[bradwilson]

What's the quickest way to repro this problem?

The master branch of https://github.com/xunit/xunit exhibits the build failure if you uncomment the line where I've commented out your library. You just need to run ./build from the root of the clone (you will need .NET Core 2.1 and latest Mono installed).

I can't find a docker image.

I don't think anybody makes Pop Docker containers, since it's basically just UI improvements on top of Ubuntu.

Is Pop OS based on Ubuntu 20?

Yes, Pop is based on Ubuntu, and they keep the equivalent version numbers (20.04 of Pop is based on 20.04 of Ubuntu).

One thing that is making me wonder: I do know that they've changed the way the operating system identifies itself with Ansible; previously it simply identified itself as Ubuntu with a variety of Debian; now it's identified as Pop!_OS with no variety indicator at all. Maybe whatever is causing that, is also causing .NET Core and/or libgit2sharp to not know how to properly identify the operating system?

[bradwilson]

you will need .NET Core 2.1... installed

Apparently I'm depending on a newer SDK than 2.1 (for dotnet tool restore), so you'll want to install at minimum .NET SDK 3.1 with the .NET Core 2.1 runtime (you can install both SDKs, though that's mild overkill).

[AArnott]

Maybe whatever is causing that, is also causing .NET Core and/or libgit2sharp to not know how to properly identify the operating system?

That sounds very likely. I'll start there.

[AArnott]

I set up a VM and the problem repros trivially without xunit, as I suspected. It's probably just a missing RID in this list:

https://github.com/dotnet/Nerdbank.GitVersioning/blob/200a7c2f4e23c3520443b9ef0da1e557f4af9033/src/Nerdbank.GitVersioning.Tasks/RuntimeIdMap.cs

[bradwilson]

Awesome! Thanks!

[AArnott]

Can you consume from our PublicCI feed to verify till we push to nuget.org?

[bradwilson]

Sure, I'll give it a try later today. What's the server URL?

[AArnott]

I added a paragraph near the bottom of the Readme that gives the location.

[bradwilson]

Verified that 3.2.17-beta-gceb8927950 does fix the problem. Thanks for the quick turnaround!

[bradwilson]

Hmm, now I'm back to having Omnisharp problems. Not sure if it's Pop 20.04 related or not. Happy to open a new issue if you think that's best:

[fail]: OmniSharp.MSBuild.ProjectLoader
        The "Nerdbank.GitVersioning.Tasks.GetBuildVersion" task failed unexpectedly.
System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.DllNotFoundException: lib/linux-x64/libgit2-106a5f2.so assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) LibGit2Sharp.Core.NativeMethods.git_libgit2_init()
  at LibGit2Sharp.Core.NativeMethods.InitializeNativeLibrary () [0x00002] in <c6ddab362adb4977b9e6460e3b7d98f1>:0 
  at LibGit2Sharp.Core.NativeMethods..cctor () [0x00045] in <c6ddab362adb4977b9e6460e3b7d98f1>:0 
   --- End of inner exception stack trace ---
  at LibGit2Sharp.Core.Proxy.git_libgit2_opts_set_search_path (LibGit2Sharp.ConfigurationLevel level, System.String path) [0x00000] in <c6ddab362adb4977b9e6460e3b7d98f1>:0 
  at LibGit2Sharp.GlobalSettings.SetConfigSearchPaths (LibGit2Sharp.ConfigurationLevel level, System.String[] paths) [0x0001a] in <c6ddab362adb4977b9e6460e3b7d98f1>:0 
  at Nerdbank.GitVersioning.GitExtensions.OpenGitRepo (System.String pathUnderGitRepo, System.Boolean useDefaultConfigSearchPaths) [0x00025] in <a0ce1227900042f1a02260a39c1b43c6>:0 
  at Nerdbank.GitVersioning.VersionOracle.Create (System.String projectDirectory, System.String gitRepoDirectory, Nerdbank.GitVersioning.ICloudBuild cloudBuild, System.Nullable`1[T] overrideBuildNumberOffset, System.String projectPathRelativeToGitRepoRoot) [0x00017] in <a0ce1227900042f1a02260a39c1b43c6>:0 
  at Nerdbank.GitVersioning.Tasks.GetBuildVersion.ExecuteInner () [0x000c5] in <252bee3785764a9da15ee71b5fe50174>:0 
  at MSBuildExtensionTask.ContextAwareTask.Execute () [0x0005e] in <252bee3785764a9da15ee71b5fe50174>:0 
  at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute () [0x00029] in <830c917fa9624a509f2f0b5c2bce30f9>:0 
  at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask (Microsoft.Build.BackEnd.ITaskExecutionHost taskExecutionHost, Microsoft.Build.BackEnd.Logging.TaskLoggingContext taskLoggingContext, Microsoft.Build.BackEnd.TaskHost taskHost, Microsoft.Build.BackEnd.ItemBucket bucket, Microsoft.Build.BackEnd.TaskExecutionMode howToExecuteTask) [0x002a9] in <830c917fa9624a509f2f0b5c2bce30f9>:0 
[warn]: OmniSharp.MSBuild.ProjectManager
        Failed to load project file '/home/bradwilson/dev/xunit/xunit/src/xunit.v3.abstractions/xunit.v3.abstractions.csproj'.
/home/bradwilson/dev/xunit/xunit/src/xunit.v3.abstractions/xunit.v3.abstractions.csproj
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/Nerdbank.GitVersioning.targets(71,5): Error: The "Nerdbank.GitVersioning.Tasks.GetBuildVersion" task failed unexpectedly.
System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.DllNotFoundException: lib/linux-x64/libgit2-106a5f2.so assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) LibGit2Sharp.Core.NativeMethods.git_libgit2_init()
  at LibGit2Sharp.Core.NativeMethods.InitializeNativeLibrary () [0x00002] in <c6ddab362adb4977b9e6460e3b7d98f1>:0 
  at LibGit2Sharp.Core.NativeMethods..cctor () [0x00045] in <c6ddab362adb4977b9e6460e3b7d98f1>:0 
   --- End of inner exception stack trace ---
  at LibGit2Sharp.Core.Proxy.git_libgit2_opts_set_search_path (LibGit2Sharp.ConfigurationLevel level, System.String path) [0x00000] in <c6ddab362adb4977b9e6460e3b7d98f1>:0 
  at LibGit2Sharp.GlobalSettings.SetConfigSearchPaths (LibGit2Sharp.ConfigurationLevel level, System.String[] paths) [0x0001a] in <c6ddab362adb4977b9e6460e3b7d98f1>:0 
  at Nerdbank.GitVersioning.GitExtensions.OpenGitRepo (System.String pathUnderGitRepo, System.Boolean useDefaultConfigSearchPaths) [0x00025] in <a0ce1227900042f1a02260a39c1b43c6>:0 
  at Nerdbank.GitVersioning.VersionOracle.Create (System.String projectDirectory, System.String gitRepoDirectory, Nerdbank.GitVersioning.ICloudBuild cloudBuild, System.Nullable`1[T] overrideBuildNumberOffset, System.String projectPathRelativeToGitRepoRoot) [0x00017] in <a0ce1227900042f1a02260a39c1b43c6>:0 
  at Nerdbank.GitVersioning.Tasks.GetBuildVersion.ExecuteInner () [0x000c5] in <252bee3785764a9da15ee71b5fe50174>:0 
  at MSBuildExtensionTask.ContextAwareTask.Execute () [0x0005e] in <252bee3785764a9da15ee71b5fe50174>:0 
  at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute () [0x00029] in <830c917fa9624a509f2f0b5c2bce30f9>:0 
  at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask (Microsoft.Build.BackEnd.ITaskExecutionHost taskExecutionHost, Microsoft.Build.BackEnd.Logging.TaskLoggingContext taskLoggingContext, Microsoft.Build.BackEnd.TaskHost taskHost, Microsoft.Build.BackEnd.ItemBucket bucket, Microsoft.Build.BackEnd.TaskExecutionMode howToExecuteTask) [0x002a9] in <830c917fa9624a509f2f0b5c2bce30f9>:0

I do see the library, but I wonder if it should be picking the ubuntu.18.04 version instead...?

 sh$ find ~/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/ -name "*.so"
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/linux-x64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/ubuntu.16.04-arm64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/debian.9-x64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/fedora-x64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/alpine-x64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/debian-arm64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/alpine.3.9-x64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/ubuntu.18.04-x64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/runtimes/rhel-x64/native/libgit2-106a5f2.so
/home/bradwilson/.nuget/packages/nerdbank.gitversioning/3.2.17-beta-gceb8927950/build/MSBuildFull/lib/linux-x64/libgit2-106a5f2.so

[bradwilson]

Actually, I'm pretty sure that's the problem. Here's the ldd outputs for the two libraries:

linux-x64/native/libgit2-106a5f2.so:

    linux-vdso.so.1 (0x00007ffeb053a000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fd43a9ab000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd43a988000)
    libssl.so.1.0.0 => not found
    libcrypto.so.1.0.0 => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd43a796000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fd43acfc000)

ubuntu.18.04-x64/native/libgit2-106a5f2.so:

    linux-vdso.so.1 (0x00007fa8c918d000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa8c8e2e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa8c8e0b000)
    libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fa8c8d78000)
    libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fa8c8aa2000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa8c88b0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa8c918e000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa8c88aa000)

[bradwilson]

I have validated that the Omnisharp problem happens with stock Ubuntu 20.04 as well, trying (and failing) to load the same library, which may mean a new issue should be opened.

Here is (the relevant parts of) dotnet --info from Ubuntu 20.04:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.300
 Commit:    b2475c1295

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.300/

And Pop 20.04 looks the same:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.300
 Commit:    b2475c1295

Runtime Environment:
 OS Name:     pop
 OS Version:  20.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.300/

Host (useful for support):
  Version: 3.1.4
  Commit:  0090613580

Note that both have an RID of linux-x64. Here's the relevant bits from Ubuntu 18.04:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.300
 Commit:    b2475c1295

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.300/

Host (useful for support):
  Version: 3.1.4
  Commit:  0090613580

I'm still doing a couple more experiments to see how other versions of Pop and Ubuntu fare.

[bradwilson]

Pop 19.10 has a good RID:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.300
 Commit:    b2475c1295

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  19.10
 OS Platform: Linux
 RID:         ubuntu.19.10-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.300/

Host (useful for support):
  Version: 3.1.4
  Commit:  0090613580

[bradwilson]

Strangely, though, it looks like Omnisharp is still trying to load the linux-x64 library instead of the ubuntu.18.04-x64 library on Pop 19.10, despite the seemingly better RID. Who is responsible for the fallback logic from ubuntu.19.10-x64 down to previous versions of Ubuntu, rather than just reverting directly to linux-x64? Is that you, or is that something inside .NET Core?

[bradwilson]

Your comment here makes me suspect you don't support plan to support 19.10, and are instead hoping for the managed HTTPS implementation (which drops the need for libssl and libcrypto): https://github.com/dotnet/Nerdbank.GitVersioning/issues/417#issuecomment-606024860

That's a sort of fix, but I am left to wonder how RID fallback is supposed to work, and who's responsible for implementing it.

[bradwilson]

Opened an issue related to the missing RID for Ubuntu 20.04: https://github.com/dotnet/runtime/issues/37000

[AArnott]

My change was indeed intended to get Pop!_OS 20 to consume Ubuntu 18 binaries. I don't yet understand why it would work at the command line and not Omnisharp unless perhaps the .NET Core SDK used by the two are different.
It sounds like your latest theory though (thanks for all the research) is that RuntimeEnvironment.GetRuntimeIdentifier() as called here:

https://github.com/dotnet/Nerdbank.GitVersioning/blob/8e21b4bbe596a11c219829751cd28a6aabcec3c1/src/Nerdbank.GitVersioning.Tasks/GitLoaderContext.cs#L64

is returning linux-x64 instead of the Pop!_OS RID, in which case I don't know if there's anything I can do to make it work (without changing the way NB.GV detects OS's anyway) until the bug you filed against .NET Core is fixed.

[AArnott]

What I don't understand is why when I call RuntimeEnvironment.GetRuntimeIdentifier() directly on Pop!_OS, it returns pop.20.04-x64 but dotnet --info returns linux-x64. I guess dotnet --info is returning the closest recognized value (with poor matching as you described) while the API I'm calling returns the original value.
And at the command line, nbgv correctly matches against ubuntu-18 using the fallback tables I modified in nbgv.
I don't yet know why omnisharp fails. Looking more...

[AArnott]

Oh! But omnisharp runs on _mono_, right? So maybe mono is returning the wrong RID from that API.

[AArnott]

mono 6.8.0.105 returns the same RID as .NET Core. I wonder if Omnisharp ships an older mono runtime that doesn't recognize Pop!_OS.

[bradwilson]

That could very well be. Pop!_OS 20.04 (and Ubuntu 20.04) are only about a month old, so it's reasonable to assume any changes that might need to be made haven't been made yet.

In addition, I have latest Mono installed on my box, but I don't know whether Omnisharp uses that, or brings along an embedded version of Mono. So we may be fighting two separate battles here (getting Mono to recognize Pop and/or getting Omnisharp to ship a newer Mono, if it is indeed embedded).

[AArnott]

Omnisharp does indeed use its own mono. I know because omnisharp works on all my machines although I don't have mono on them.

[AArnott]

I can repro the omnisharp failure. Thinking more about this, maybe it has nothing to do with RIDs, and everything to do with the libgit2sharp.dll.config file. Mono uses this file (which .NET and .NET Core ignore) to find native dependencies, so there's no RID map. It can only point to just the one dll, at the path specified in that file.

I just tested this theory. I changed LibGit2Sharp.dll.config on the Pop!_OS machine's nuget package cache so that the target= attribute is set to ../runtimes/ubuntu.18.04-x64/native/libgit2-106a5f2.so and omnisharp suddenly started working.

@bording, is there any way to improve libgit2sharp's ability to load native dll's on mono so that it varies by RID?

[bording]

@bording, is there any way to improve libgit2sharp's ability to load native dll's on mono so that it varies by RID?

I'm not sure that there is. Mono doesn't understand RIDs at all, just the dll.config mechanism, and that is very limited in what it can support.

Linux also doesn't let you alter the load path after a process is started, so there's no way I know of to influence where mono is looking when it finds DllImport attributes,

The only way I'm currently aware of to "fix" this is for the managed implementation work to get done, which should mean we only have a single native binary to point to per architecture, so I think the dll.config can work.

Though, it's sill likely to be an issue for Alpine since it doesn't use libc.

[AArnott]

@bording would a LoadLibrary call at the RID based path before calling the p/invoke do the trick? I heard that only a single module with a given name can be loaded (on Windows), so might that mean on Linux we can load the right one on mono and mono would then be obliged to use it?

[AArnott]

I discovered that by removing the path from the target attribute of the .dll.config file, leaving only the libgit2-106a5f2.so filename, that I could get it to work on Pop!_OS by setting the LD_LIBRARY_PATH environment variable to the path of the ubuntu-18 so file when invoking mono.
Sadly though, setting that env var _within_ the mono process did _not_ work, so this doesn't give me a way to help mono at runtime to find the dll. :(

[AArnott]

Unless more comes to light, I think we'll just close this in anticipation of libgit2sharp eventually dropping the ssl dependency as @bording said.

[bording]

@bording would a LoadLibrary call at the RID based path before calling the p/invoke do the trick?

From experimenting with that idea in the past it seems that doing that does not seem to work on Linux. I have heard something about it possibly being related to the specific soname inside the native binaries, so perhaps altering that could get that approach to work.

Of course, even if it did, that means the entire RID parsing logic would have to be duplicated inside LibGit2Sharp, and we'd have to continue the madness that is trying to ship a native binary for the ever-expanding set of Linux distros supported by .NET Core.

The managed approach is the only real way to fix it.

[AArnott]

even if it did, that means the entire RID parsing logic would have to be duplicated inside LibGit2Sharp,
Actually I was expecting to do it inside of nb.gv. We already have that logic, and we would just reuse it for the mono runtime too.

But ya, managed ssl all the way is great.

[bording]

But ya, managed ssl all the way is great.

Speaking of which, be sure to check out my latest update on the PR for that. Hit some snags after working on it more this weekend.

[m0sa]

Hi, landed here since I'm hitting the same issue on the default dotnet devcontainer image (both mcr.microsoft.com/vscode/devcontainers/dotnet:dev-5.0 and 3.1), they are based on ubuntu 20.04 / dotnet SDK image: https://github.com/microsoft/vscode-dev-containers/blob/master/containers/dotnet/.devcontainer/base.Dockerfile

I've managed to work around it by adding an environment variable to the devcontainer, so I can put a condition on the packagereference, since I need devcontainers to work for development (& intellisense), not CI builds.

[AArnott]

@m0sa Curious. When I run that same dotnet:dev-5.0 docker image and install the nbgv tool, it works immediately for me.
And is there some relevance your experience is to Pop!_OS which this issue is about?

[m0sa]

This is not strictly related to Pop!_OS, but rather to all ubuntu 20.04 based images.

I'm toying around with adding support for git codespaces / devcontainers to StackExchange.Redis https://github.com/StackExchange/StackExchange.Redis/pull/1621.

I had to add this condition: https://github.com/StackExchange/StackExchange.Redis/pull/1621/files#diff-5c1900dca99df01c3ddc3a884282164b04deee76e79b176e2d34cfa47f3b8907L8

If I revert it, I get this from omnisharp (which prevents intellisense etc from working:

It is only happening in combination with omnisharp, though. A command-line dotnet build command works fine.

[AArnott]

@m0sa Ya, Omnisharp is a unique beast. It uses mono instead of .NET Core, and mono doesn't support selectively choosing where native dependencies get loaded from to the same extent that .NET Core does. But we _do_ have a fix coming soon for this. see #521 .

[m0sa]

Ah, good to know.

As a side-note @AArnott, is there a reason/need for this package's build tooling to run during design time builds (in omnisharp, but also in other IDEs)? I'd expect a design time build check Condition="'$(DesignTimeBuild)' == 'true' OR '$(BuildingProject)' != 'true'" somewhere in your custom .targets (the obvious places being here or here).

[AArnott]

Yes, it must run at design time to generate the ThisAssembly class so that intellisense can see it.