Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for additional assembly metadata in AssemblyInfo.cs #895
My use-case is that I'd like to include additional git metadata in the assembly on top of
For example, here are some lines that I would like to append to my
I like these assembly attributes because they're easy to examine across multiple assemblies.
Obviously the git values are already available, and it would be nice to be able to use the existing logic to add/replace these attributes in the
There's a case to be made that
I would imagine these names + value formats could be configured using command-line parameters or using the GitVersion.yml file.
I'm willing and interested in implementing this if you think it's something you would accept if well implemented.
@johncrim Seems like a lot of the stuff you're after is already embedded in the assembly through the autogenerated
@asbjornu - thank you for the response.
The static class is suboptimal for a couple reasons:
@johncrim Those are good points. I'd like to fix them in another way, though. There's some relevant discussions on the reasons behind using a static class in OctopusDeploy/OctoPack#69 and #531. @SimonCropp's example there, illustrates it quite well:
var assemblyName = assembly.GetName().Name; var gitVersionInformationType = assembly.GetType(assemblyName + ".GitVersionInformation"); var versionField = gitVersionInformationType.GetField("NuGetVersion"); Trace.WriteLine(versionField.GetValue(null)); var gitVersionInformationAttributeType = assembly.GetType(assemblyName + ".GitVersionInformationAttribute"); var attribute = assembly.GetCustomAttribute(gitVersionInformationAttributeType); var attributeVersionField = gitVersionInformationAttributeType.GetProperty("NuGetVersion"); Trace.WriteLine(attributeVersionField.GetValue(attribute));
Since the attribute is an instance, it requires one extra line of reflection code to extract. Therefore, my suggestion is to consolidate the assemblyinfo update logic as per #883, such that any discrepancy between GitVersionTask and GitVersion.exe (as well as the different supported languages; C#, Visual Basic and F#) that now exists, go away.
It's obvious that the MSBuild task and the EXE should behave the same way across all languages, but that's currently sadly not the case. If you're up for tackling that, I'd be more than happy to merge your pull request.
We can do this in baby steps, where the first PR just injects the
What do you think?
I'm willing to give it a go using whatever approach provides the best utility for the community.
I agree 100% that
I've reviewed the issues you referenced, and I don't see an explanation for why a static class is preferable to assembly attributes - can you shed some more light on that?
Obviously assembly attributes are a key part of the assembly design and are used for binding and assembly versioning already. They're exposed by disassembly tools, etc.
For my purposes, I already have some tools that expose assembly version info and
If this feature is only implemented using a static internal class, then anyone consuming gitversion-created assembly metadata will have to consume it differently than they consume other assembly metadata. Since gitversion is a build tool it seems reasonable to me to support emitting the info in whatever form works best for the consumer.
How do you feel about me attempting support for both use-cases?