Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Provide .NET 4.6.1 framework target #1606
Conversation
|
It would seem MSBuild property |
|
@devlead wooo |
|
Ok checking MSBuild log seems |
|
@devlead Yeah, since this PR adds multi-targeting, that will be an issue. We'll have to update LibGit2Sharp.NativeBinaries first before we can move forward with this. |
|
@bording tested with package generated from libgit2/libgit2sharp.nativebinaries#75 https://ci.appveyor.com/project/devlead/libgit2sharp-nativebinaries/build/1.0.1 And then I could successfully build a nuget package. |
|
Neat! Once the NativeBinaries changes are ready to go, we'll merge this. Thanks! |
|
@ethomson Just an FYI I do have some review comments to make before we merge this, but I was waiting for the NativeBinaries update. |
|
@bording I have now updated libgit2/libgit2sharp.nativebinaries#75 to import and not copy. |
|
libgit2/libgit2sharp.nativebinaries#75 has been released as LibGit2Sharp.NativeBinaries 1.0.233, so you can update this PR to use it. |
|
@bording native binaries updated and PR rebased. |
Azure Pipelines currently doesn't allow setting build numbers on PRs, whish thet did, but that's why builds are failing. But Mac / Linux |
Cool, I should be able to look over this tomorrow then. |
| @@ -7,4 +7,8 @@ | |||
| <DefineConstants Condition=" '$(ExtraDefine)' != '' ">$(DefineConstants);$(ExtraDefine)</DefineConstants> | |||
| </PropertyGroup> | |||
|
|
|||
| <PropertyGroup Condition=" '$(TargetFramework)' == 'netstandard2.0' "> | |||
| <DefineConstants>$(DefineConstants);NETCORE</DefineConstants> | |||
bording
Sep 18, 2018
Member
Instead of defining a new constant, let's use the built-in ones: NETCOREAPP, NETSTANDARD, and NETFRAMEWORK
Instead of defining a new constant, let's use the built-in ones: NETCOREAPP, NETSTANDARD, and NETFRAMEWORK
devlead
Sep 19, 2018
Author
Contributor
Reverted.
Reverted.
| @@ -13,11 +13,16 @@ internal enum OperatingSystemType | |||
| internal static class Platform | |||
| { | |||
| public static string ProcessorArchitecture => IntPtr.Size == 8 ? "x64" : "x86"; | |||
| #if !NETCORE | |||
| private static bool? _isRunningOnMac; | |||
| public static bool IsRunningOnMac() => _isRunningOnMac ?? (_isRunningOnMac = TryGetIsRunningOnMac()) ?? false; | |||
bording
Sep 18, 2018
Member
Not sure we need this to be public.
Not sure we need this to be public.
devlead
Sep 19, 2018
Author
Contributor
Internal class, but sure made it private.
Internal class, but sure made it private.
|
|
||
| #if !NETCORE | ||
| #pragma warning disable IDE1006 // Naming Styles | ||
| [DllImport("libc")] |
bording
Sep 18, 2018
Member
Is there a danger here of this throwing? For example, what if we're running on a musl libc instead of glibc?
Is there a danger here of this throwing? For example, what if we're running on a musl libc instead of glibc?
ethomson
Sep 19, 2018
Member
Unlikely to find a system without libc (even if it’s not glibc) but this is not ideal. uname takes a struct of char arrays (of a well defined size) not a single char array. So this should work everywhere (since it’s an appropriately large buffer) but I don’t love it.
I don’t think that libgit2 has a mechanism to tell you what OS you’re running on, but it seems like we could.
But without that, I think I would recommend sysctl instead of uname.
Unlikely to find a system without libc (even if it’s not glibc) but this is not ideal. uname takes a struct of char arrays (of a well defined size) not a single char array. So this should work everywhere (since it’s an appropriately large buffer) but I don’t love it.
I don’t think that libgit2 has a mechanism to tell you what OS you’re running on, but it seems like we could.
But without that, I think I would recommend sysctl instead of uname.
devlead
Sep 19, 2018
Author
Contributor
Is there a danger here of this throwing? For example, what if we're running on a musl libc instead of glibc?
libc should not be an issue.
I don’t think that libgit2 has a mechanism to tell you what OS you’re running on, but it seems like we could.
As this is used to decide how to load libgit, I don't see how we could use it, right?
But without that, I think I would recommend sysctl instead of uname.
Used uname trick for years in Mono projects, so didn't think of sysctl will investigate.
Is there a danger here of this throwing? For example, what if we're running on a musl libc instead of glibc?
libc should not be an issue.
I don’t think that libgit2 has a mechanism to tell you what OS you’re running on, but it seems like we could.
As this is used to decide how to load libgit, I don't see how we could use it, right?
But without that, I think I would recommend sysctl instead of uname.
Used uname trick for years in Mono projects, so didn't think of sysctl will investigate.
devlead
Sep 19, 2018
Author
Contributor
Haven't looked at sysctl implementation yet, but while seeking inspiration it does seem many use uname for os detection and then sysctl for kernel revision detection, wonder if there's some reasoning around that.
https://github.com/dotnet/corefx/blob/0566028e42a8f2fa86b8e0dd856d1f13d0fdce05/src/Native/Unix/System.Native/pal_runtimeinformation.c#L25-L39
Could be a legacy from the project "k" days, which I now see also used uname
https://github.com/aspnet/PlatformAbstractions/blob/174f51f3180ac9718de48d155b819e8a05310ab0/src/Microsoft.Extensions.PlatformAbstractions/Native/NativeMethods.Unix.cs#L10-L27
Maybe sysctl kern.ostype is good enough will give it a go and refactor PR.
Haven't looked at sysctl implementation yet, but while seeking inspiration it does seem many use uname for os detection and then sysctl for kernel revision detection, wonder if there's some reasoning around that.
https://github.com/dotnet/corefx/blob/0566028e42a8f2fa86b8e0dd856d1f13d0fdce05/src/Native/Unix/System.Native/pal_runtimeinformation.c#L25-L39
Could be a legacy from the project "k" days, which I now see also used uname
https://github.com/aspnet/PlatformAbstractions/blob/174f51f3180ac9718de48d155b819e8a05310ab0/src/Microsoft.Extensions.PlatformAbstractions/Native/NativeMethods.Unix.cs#L10-L27
Maybe sysctl kern.ostype is good enough will give it a go and refactor PR.
devlead
Sep 19, 2018
Author
Contributor
Refactored PR to use sysctl and kern.ostype.
Refactored PR to use sysctl and kern.ostype.
9a2f0b5
to
9fce228
| @@ -13,11 +13,16 @@ internal enum OperatingSystemType | |||
| internal static class Platform | |||
| { | |||
| public static string ProcessorArchitecture => IntPtr.Size == 8 ? "x64" : "x86"; | |||
| #if !NETSTANDARD | |||
bording
Sep 19, 2018
Member
I want to change this eventually, but Platform.cs is also included in the Tests project, so using NETSTANDARD here means the test project has these members defined when they don't need to be.
To make this work in both places, basing the logic on NETFRAMEWORK is going to be the way to go.
I want to change this eventually, but Platform.cs is also included in the Tests project, so using NETSTANDARD here means the test project has these members defined when they don't need to be.
To make this work in both places, basing the logic on NETFRAMEWORK is going to be the way to go.
devlead
Sep 20, 2018
Author
Contributor
Addressed
Addressed
* adds Pollyfil for System.Runtime.InteropServices.RuntimeInformation * fixes #1605
|
@bording ready for next release? |
|
@jrgcubano well @bording seems happy ;) |
|
Can we get a new release to nuget.org with this fix please? |
|
Interesting the GH release 0.25.3 has this PR in it But the NuGet release seems to have been done from Which doesn't have this pr in it, so currently the release doesn't match the release binaries But perhaps that was unintentional and this will come in 0.26.0? |
That link shows you what isn't in 0.25.3. The last release was 0.26.0-preview-0027, built from this commit, which does not include this PR. |
|
Ok I just clicked commits on the release |
|
That's a misleading link, I guess. But look carefully at the wording of that link:
|
|
Ah sorry you're correct. |
@AArnott: you bet - https://www.nuget.org/packages/LibGit2Sharp/0.26.0-preview-0054 |


As discuessed in #1605