Add ThisAssembly.Git #69
Labels
enhancement
New feature or request
Comments
|
The biggest problem with doing this as a source generator is that SG should not do I/O (in fact, recommendation is that no SG should take more than 10ms to complete). Getting git info would require doing I/O to open the files .git uses to read the data it needs. Recommend that the current path (build task in GitInfo) is the proper way to do this. |
|
SourceLink already populates most (all?) of the information GitInfo calculates. So perhaps it's mostly just exposing those to .NET code... |
|
To make sure I understand: the SG would not store the values, simply the code that access the data present in the SourceLink area? |
|
Yep, that's the idea... to avoid redoing anything that is already solved by sourcelink itself.. Perhaps we could add reading of the RepositoryBranch (which is a valid metadata item for nuget pack) (perhaps just by reading the HEAD from MSBuild and making it visible to the SG... |
kzu
added a commit
that referenced
this issue
Jan 25, 2023
This opens up other scenarios for specific constants we don't want behind a Constants propery (i.e ThisAssembly.Git, see #69). A small refactoring of the targets with a new PrepareConstants will also make it easier for extenders to run before we do our conversion to AdditionalFiles, to keep the extended items clean even when they need to run before/after certain targets.
kzu
added a commit
that referenced
this issue
Jan 25, 2023
This opens up other scenarios for specific constants we don't want behind a Constants propery (i.e ThisAssembly.Git, see #69). A small refactoring of the targets with a new PrepareConstants will also make it easier for extenders to run before we do our conversion to AdditionalFiles, to keep the extended items clean even when they need to run before/after certain targets.
kzu
added a commit
that referenced
this issue
Jan 25, 2023
…y.Constants This new package is just targets that leverage git-based SourceLink packages (which must be installed separately since there is a variety) to populate source control information, turn it into constants that then the ThisAssembly.Constants package surfaces in a standard manner. We do not force run of source control queries in design-time builds, unless the user forces it. This keeps the performance characteristics of SourceLink, at the expense of a slightly confusing user experience where intellisense might show the properties as empty all the time while in fact it's just during design-time. Closes #69
kzu
added a commit
that referenced
this issue
Jan 25, 2023
This opens up other scenarios for specific constants we don't want behind a Constants propery (i.e ThisAssembly.Git, see #69). A small refactoring of the targets with a new PrepareConstants will also make it easier for extenders to run before we do our conversion to AdditionalFiles, to keep the extended items clean even when they need to run before/after certain targets.
kzu
added a commit
that referenced
this issue
Jan 25, 2023
…y.Constants This new package is just targets that leverage git-based SourceLink packages (which must be installed separately since there is a variety) to populate source control information, turn it into constants that then the ThisAssembly.Constants package surfaces in a standard manner. We do not force run of source control queries in design-time builds, unless the user forces it. This keeps the performance characteristics of SourceLink, at the expense of a slightly confusing user experience where intellisense might show the properties as empty all the time while in fact it's just during design-time. Closes #69
kzu
added a commit
that referenced
this issue
Jan 25, 2023
…y.Constants This new package is just targets that leverage git-based SourceLink packages (which must be installed separately since there is a variety) to populate source control information, turn it into constants that then the ThisAssembly.Constants package surfaces in a standard manner. We do not force run of source control queries in design-time builds, unless the user forces it. This keeps the performance characteristics of SourceLink, at the expense of a slightly confusing user experience where intellisense might show the properties as empty all the time while in fact it's just during design-time. Closes #69
kzu
added a commit
that referenced
this issue
Jan 25, 2023
…y.Constants This new package is just targets that leverage git-based SourceLink packages (which must be installed separately since there is a variety) to populate source control information, turn it into constants that then the ThisAssembly.Constants package surfaces in a standard manner. We do not force run of source control queries in design-time builds, unless the user forces it. This keeps the performance characteristics of SourceLink, at the expense of a slightly confusing user experience where intellisense might show the properties as empty all the time while in fact it's just during design-time. Closes #69
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is something that GitInfo provides, but it does so using MSBuild and it seems to cause an issue in some source-generator scenarios.
So perhaps it would be best if the codegen part was provided by a source generator in this project instead, with GitInfo detecting its presence (via a ThisAssemblyGitInfo=true property perhaps?) and avoid generating the
ThisAssembly.Gitpart of the code.It might even make sense for GitInfo to take a dependency on the new
ThisAssembly.Gitentirely and just augment it for the semver determination.This implementation should likely rely on SourceLink implementation for some information retrieval, and take a dependency on it to avoid duplicating work?
The text was updated successfully, but these errors were encountered: