SourceLink revision detection fails when version contains build information

[delreluca]

We set the build info part of the version ourselves to add additional information (e.g. via -p:Version=1.2.3-alpha+build.42) SourceLink will then turn it into 1.2.3-alpha+build.42.revisionFromSourceLink.

See the MSBuild target which adds a . if there already is a +:

https://github.com/dotnet/sdk/blob/df4091f0cc6803f81fa7681ed72c828525db701a/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets#L67-L71

However this library will use the whole build info part which will return non-sense in front of the SourceLink revision in this case:

dd-trace-dotnet/tracer/src/Datadog.Trace/PDBs/SourceLinkInformationExtractor.cs

Lines 116 to 122 in 259d478

	case AssemblyInformationalVersionAttribute { InformationalVersion: { } informationalVersion }:
	{
	var parts = informationalVersion.Split('+');
	if (parts.Length == 2)
	{
	commitSha = parts[1];
	}

Easy fix would be to use parts[1].Split('.').Last()

Ideally we could check whether it’s a valid revision (but that might be hard if there are multiple supported VCS and formats), since one can turn off IncludeSourceRevisionInInformationalVersion or GenerateAssemblyVersionInformationalAttribute without turning off GenerateRepositoryUrlAttribute.

[delreluca]

Apparently this was caused by setting a wrong RepositoryUrl in my csproj (or rather not deleting it, as with the current SDK it’s optional). Removing it makes the commit hash detection work again.

So it seems like this code path is only a problem when the repository URL is wrong (commit hash in version was correct)