publish temporary SourceLink.LibGit2Sharp to NuGet Gallery that support dotnet core

[ctaggart]

libgit2/libgit2sharp#1318 (comment)

Cool. I hadn't ready about dotnet CLI tools before. Does that mean someone running Source Link has to run it as a separate build step instead of having it integrated in the build like PdbGit/GitLink3 have?

@AArnott No, it is not an additional build step. The msbuild task is called before the compile and it simply delegates to the dotnet sourcelink tool.

I could publish my libgit2sharp fork on nuget.org by changing the package ID, but I'd consider that a last result. You (at least temporarily) embedding its content in your package or if the owners of this project published a prerelease package with my PR in it that would be preferable.

Could you please do this? I was going to publish a SourceLink.LibGit2Sharp. You have my permission to do so. I just plan on unlisting it once there is an official build.

<PackageReference Include="LibGit2Sharp" Version="0.24.7-g9fca61fdda" />
https://github.com/ctaggart/SourceLink/blob/v2/dotnet-sourcelink-git/dotnet-sourcelink-git.csproj#L18

<add key="aarnott" value="https://www.myget.org/F/aarnott/api/v3/index.json" protocolVersion="3" />
https://github.com/ctaggart/SourceLink/blob/v2/NuGet.Config#L6

[AArnott]

The msbuild task is called before the compile

before the compile? What does it do? Don't you need a PDB to do the work? Or is the new roslyn feature of passing a JSON file to the compiler so the PDB is written correctly the first time done and you're leveraging it?

If you have a dotnet CLI tool and an MSBuild extension, do you have to have two NuGet packages, such that one is a PackageReference and the other is a DotNetCliTool?

I'll publish a LibGit2Sharp.CoreCLR package (or named something like that) that you can consume by end of day (pacific time zone). And I like your policy of unlisting it once the official one offers equivalent functionality.

[ctaggart]

before the compile? What does it do?

Yes, it just creates a json file for the new format. The file location is passed in to the compilers via /sourcelink param. Since it is before the compile, we can adjust the line endings if needed. We can also tell it to /embed files that are not in the repo. GitTools/GitLink#115

If you have a dotnet CLI tool and an MSBuild extension, do you have to have two NuGet packages, such that one is a PackageReference and the other is a DotNetCliTool?

Currently, it will looks like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
    <DebugType>Portable</DebugType>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="SourceLink.Create.GitHub" Version="2.0.0-*" />
    <DotNetCliToolReference Include="dotnet-sourcelink-git" Version="2.0.0-*" />
  </ItemGroup>
</Project>

I'm hoping that <PackageReference Include="SourceLink.Create.GitHub" Version="2.0.0-*" /> can somehow just depend on <DotNetCliToolReference Include="dotnet-sourcelink-git" Version="2.0.0-*" />, but need to ask the dotnet cli guys how to do that.

I'll publish a LibGit2Sharp.CoreCLR package (or named something like that) that you can consume by end of day (pacific time zone). And I like your policy of unlisting it once the official one offers equivalent functionality.

Thanks. I'm a few issues away from pushing a build. If not tonight, then early this week. cc @tmat

[AArnott]

I don't think you'll get the dependencies the way you want. At least not in the near future. So I advocate for optimizing for easy consumption in the near term, by just having the msbuild extension package that bundles everything.

[ctaggart]

Copying two lines to a .csproj instead of one to enable source linking isn't terrible. I want the msbuild extension package to be just a simple wrapper, so I'm probably not going to bundle everything. I really like how the dotnet cli tools extensions load all dependencies from the .nuget cache.

[tmat]

Since it is before the compile, we can adjust the line endings if needed.

@ctaggart Are you thinking copying the input source files to temp dir and replacing the line endings there? Interesting idea, but I'm not sure if that's ideal.

I just hit the line ending issue with Roslyn. Roslyn build server normalizes line endings when checking out git branch to build, so GitLink is broken :(.
Our .gitattributes file currently uses auto setting.

Is it possible to override this for a particular checkout/clone command? If so then all we have to do so make sure that "official" build checks out "as is".
If this was possible with git I wouldn't bother building line ending translation into SourceLink/GitLink.

[tmat]

BTW, the reason I think it's not ideal to translate the line endings in SourceLink tool is that it's fixing behavior of git. It'd be better if it was possible to configure git to do the right thing in the first place.

[AArnott]

I haven't experienced this line ending issue. We check in LF and checkout CRLF, and my source server testing seems to work.

[AArnott]

@ctaggart Do you need this to be a stable package that I publish to nuget.org?

[ctaggart]

The line endings mismatch has plagued this project. Solutions are well documented at https://github.com/ctaggart/SourceLink/wiki/Line-Endings.

[tmat]

@AArnott The compiler calculates SHA1 of the sources files in their binary form. If the files served by https://raw.githubusercontent.com have different line endings their SHAs will be different and hence the debugger would consider them not matching.

[AArnott]

I must have my debugger set to "don't care"

[tmat]

@AArnott Probably. It might still care in some scenarios as I just found out (even if I set the option to not care). It might be a debugger bug. I sent debugger folks a repro to investigate.

[AArnott]

Or I wonder if... one might say that raw.githubcontent should offer CRLF files (just as the compiler saw) because the .gitattributes files says to.

[tmat]

@ctaggart Thanks for the link. Very useful. Sounds like we could tweak our lab build to clone "as is".

[AArnott]

appveyor does something bizarre. It checks out LF despite the .gitattributes file. It causes some tests to fail. Very annoying.

[tmat]

Or I wonder if... one might saw that raw.githubcontent should offer CRLF files

@AArnott Now that's an interesting point.

[tmat]

Perhaps we should ask github folks. If raw.githubcontent did respect the .gitattributes it would fix everything.

[AArnott]

+1. Please CC me when you do.

[ctaggart]

@AArnott Yes, a stable if you don't think one is coming out in the next week. :-)

[AArnott]

@ctaggart Here you go: https://www.nuget.org/packages/libgit2sharp.portable

[ctaggart]

I've already got the code to autofix the line endings. I just need to port to C# and add it as an option. I think that GitHub should serve the files as they are stored in Git. Git stores them as LF.

[AArnott]

@ctaggart A couple more thoughts I had in the middle of the night:

Regarding your "two lines" to be added to the project file instead of just one: does the DotNetCliToolRefrence propagate across P2Ps? If not, then actually it's 1-2 lines for every single project file, whereas a single PackageReference can propagate across P2Ps so folks can just define it in one of their commonly referenced projects in a very large solution and have it done entirely.

But perhaps most importantly, I realized when developing PdbGit that as a separate process it would slow down the build noticeably. The roslyn compilers themselves have a resident process that spans project builds because the start time for a managed process (and their own code) was large enough to impact build time significantly. And in pdbgit at least, the time taken to validate the filenames have the appropriate capitalization, find and read the repo, etc., was significant enough that I considered that doing everything within the MSBuild.exe process as part of the MSBuild Task was very important to the user's build perf. But with your design, you're adding a perf hit that you can't optimize away. I don't know how impactful that is in your case, but you may want to measure it.