Move to GitLink 3.0 #17736
Move to GitLink 3.0 #17736
Conversation
|
CC @dotnet/roslyn-ide |
|
CC @dotnet/roslyn-infrastructure Sorry IDE, that was a typo |
jaredpar
force-pushed
the
fix-gitlink
branch
2 times, most recently
from
4647060 to
1fab098
Compare
This makes two changes: 1. Move us to GitLink 3.0 1. Add source link info to all binaries we sign
|
retest windows_debug_unit32_prtest please |
| [string]$scriptDir = $PSScriptRoot | ||
|
|
||
| function Create-Directory([string]$dir) { | ||
| New-Item $dir -ItemType Directory -ErrorAction SilentlyContinue | out-null |
There was a problem hiding this comment.
What happens if it legitimately fails to create the directory?
There was a problem hiding this comment.
Then presumably the next command which uses the directory will fail 😄
I don't meant to be trolly there but there isn't a good answer to this question. Asking if the directory actually failed to create or already exists is just a variation of the File.Exists problem. I could test for existence of the directory after the call but it's a racy check.
| @@ -0,0 +1,41 @@ | |||
| # Run GitLink on the binaries that we are producing. | |||
There was a problem hiding this comment.
Can you include a comment as to why the old mechanism wasn't sufficient?
There was a problem hiding this comment.
(if the answer was "it's no longer supported", then that should have been written in the commit message)
There was a problem hiding this comment.
Sorry, I should have added more detail to this commit about that. I had put a write up of the problem in our previous convo and didn't think to add it here.
The PR has a discussion of why this approach was taken now.
This makes two changes:
The need for GitLink 3.0 is related to the efforts to no longer depend on a centralized version of MSBuild. The GitLink 2.0 approach to instrumenting PDBs was solution based and relied on having a centralized version of MSBuild installed. On a machine with multiple MSBuild installations, or a non-centrally installed version, this could lead to unpredictable or failing results.
Below is a link to a discussion I had with the GitLink team about this.
GitTools/GitLink#145
They acknowledged the problem and recommended we be an early adopter of the 3.0 toolset. This version allows for direct instrumentation of PDBs which is the style we originally preferred for source linking. The set of PDBs we ship is well known, smaller than the surface area the more general GitLink approach will hit, and gives us extra validation that our signed assembly list is correct.