Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
0.13.0
Description
With the 0.13.0 C# NuGet package, Source Link doesn't work. The symbols can be downloaded from nuget.org correctly, but when Visual Studio tries to download the code, it cannot find the correct files.
The following is why it doesn't work:
The .NET tooling expects the build of an official release to happen in the context of a git repository. This does 2 things to the produced assets:
- In the .nupkg file that is generated, the .NET tooling will encode the current git commit's SHA hash into both the Apache.Arrow.nuspec file, and into the compiled Apache.Arrow.dll assembly. Looking at the released version that was published over the weekend: https://www.nuget.org/packages/Apache.Arrow/0.13.0, this information made it into the .nuspec and the .dll:
[assembly: AssemblyInformationalVersion("0.13.0+57de5c3adffe526f37366bb15c3ff0d4a2e84655")] <repository type="git" url="https://github.com/apache/arrow" commit="57de5c3adffe526f37366bb15c3ff0d4a2e84655" />
However, I don't see how the C# release script could have done that.
- Also, .NET has a feature called "Source Link", which allows for the source code to be automatically downloaded from GitHub when debugging into this library. The way the tooling works today, it requires that the git repository's origin remote is set to https://github.com/apache/arrow.git. The tooling reads uses the `origin` git remote to encode the GitHub URL into the symbols file in the .snupkg file.
This, however, doesn't work with the 0.13.0 release that occurred over the weekend. I tried using the Source Link feature, and it didn't automatically download the source files from GitHub.
Looking into the symbols file, I see the Source Link information that was embedded:
1: '/home/kou/work/cpp/arrow.kou/apache-arrow-0.13.0/csharp/src/Apache.Arrow/Flatbuf/FlatBuffers/ByteBuffer.cs' (#19c) C# (#3) SHA-1 (#2) 04-64-A0-48-82-EA-F5-B5-50-EC-CA-9F-85-75-E2-95-A4-EC-AB-B3 (#1b7) 2: '/home/kou/work/cpp/arrow.kou/apache-arrow-0.13.0/csharp/src/Apache.Arrow/Flatbuf/FlatBuffers/ByteBufferUtil.cs' (#68f) C# (#3) SHA-1 (#2) F0-4F-28-53-88-A4-E0-6E-F1-1F-17-F6-CD-FE-0E-64-AB-0B-C2-95 (#6aa)
{ "documents": { "/home/kou/work/cpp/arrow.kou/*": "https://raw.githubusercontent.com/kou/arrow/57de5c3adffe526f37366bb15c3ff0d4a2e84655/*", "/home/kou/work/cpp/arrow.kou/cpp/submodules/parquet-testing/*": "https://raw.githubusercontent.com/apache/parquet-testing/bb7b6abbb3fbeff845646364a4286142127be04c/*" } }
Here it appears the origin remote was set to kou/arrow, and not apache/arrow. Also, it appears the apache-arrow-0.13.0 folder was under a git repository, and so the sources aren't matched up with the git repository. (Basically that folder shouldn't have appeared in the Documents list that has the .cs file path.) I think this explains how (1) above happened - the build was under a git repository - but this script downloaded an extra copy of the sources into that git repository.
I'm wondering how we can fix either this script, or the .NET Tooling, or both, to make this experience better for the next release. I think we need to ensure two things:
- The git commit information is set correctly in the .nuspec and the .dll when the release build is run. I think it just happened by pure luck this time. It just so happened that the script was executed in an already established repo, and it just so happened to be on the right commit (or maybe it wasn't the right commit?).
- The source link information is set correctly in the symbols file.
Attachments
Issue Links
- links to