Add SBRP attribute

[ellahathaway]

Fixes dotnet/source-build#3639

This PR adds the following attribute to assemblies originating from SBRP: [assembly: AssemblyInformationalVersion("<version> originated from source-build-reference-packages")]. This PR also includes logic to add this attribute as part of packageSourceGenerator.

[ellahathaway]

The duplication error from AzDo is not appearing locally. https://dev.azure.com/dnceng-public/public/_build/results?buildId=425057&view=logs&j=2f0d093c-1064-5c86-fc5b-b7b1eca8e66a&t=d2b639a6-cb19-5f1f-66fd-8047f66b3026&l=102

[ViktorHofer]

I'm not sure why we need to add this item to the generated compile source. Why can't we just define that attribute in a separate C# file and pass it to the compiler? Doing that will avoid these 600+ file changes and keep the logic contained in a single place.

EDIT: Even better, just add this this attribute via an msbuild item here: https://github.com/dotnet/source-build-reference-packages/blob/main/src/referencePackages/Directory.Build.props

    <AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
      <_Parameter1>source</_Parameter1>
      <_Parameter2>source-build-reference-packages</_Parameter2>
    </AssemblyAttribute>

[ellahathaway]

After testing the proposed implementation change, I found that the rebuilt assemblies did not include the attribute. To investigate this, I created a "dummy" dotnet app with the same code to inject the attribute and found that the attribute was added to the assemblies as intended, indicating that the proposed changes do inject the attribute as intended, but something in the build of SBRP was causing the attribute to not appear.

I discovered that this issue is the result of setting GenerateAssemblyInfo to false. As described in this issue, when GenerateAssemblyInfo is false, the project file and the project properties become out of sync. I tested this with my "dummy" dotnet app by setting "GenerateAssemblyInfo" to false and verified that the attribute does not appear in the built assembly.

However, setting GenerateAssemblyInfo to true in SBRP caused a myriad of issues, including complaints about duplicate attributes.

I have two proposed changes to address this issue:

1. Set GenerateAssemblyInfo to true but don't regenerate the duplicate assemblies. John Koerner - Dealing with Duplicate Assembly Attributes in .Net Core. I don't feel that this is a good long-term solution. Doing this means that future developers would have to manually set duplicate attributes to false as they are added.

2. Set GenerateAssemblyInfo to true and move all of the duplicate attributes out of the .cs files and into their respective .csproj files. This is more in line with the proposed change, but it would mean touching hundreds of files in this PR.

3. Manually inject the attribute as originally done.

@ViktorHofer @MichaelSimons

[MichaelSimons]

@ellahathaway - Nice discovery and analysis of what is happening.

1. Are you referring to assembly attributes that don't exist today but could be defined in the future? Even if this happened, isn't this as simple as adding a single property in the root referencePackages Directory.Build.props? Without understanding this drawback fully, this feels like the most compelling option to me.
2. Keep in mind that we do have a code generator so while it would touch a lot of files it would be done via automation. That being said, the GenAPI logic is what generates these attributes and it doesn't feel like the best choice for us to have what ever logic is necessary to specify these via the project file.

[ViktorHofer]

We don't want to generate an AssemblyInfo.cs file as GenAPI already emits all the assembly metadata into the compiled source. I think a better solution would be to just generate that C# code ourselves (basically what the GenerateAssemblyInfo target/task is doing) or even just hardcode it as a C# file and add it as a compile input.

[MichaelSimons]

We don't want to generate an AssemblyInfo.cs file as GenAPI already emits all the assembly metadata into the compiled source.

I didn't know if there would be enough knobs as to only generate the AssemblyMetadataAttribute.

[ellahathaway]

even just hardcode it as a C# file and add it as a compile input.

I think this is a good approach. I'll work on adding this.

Edit: Implemented this change as part of 2347c49

[ViktorHofer]

I assume you verified that the assembly attribute is now present? Should we add a test for it (post-merge)?

[MichaelSimons]

I assume you verified that the assembly attribute is now present? Should we add a test for it (post-merge)?

Testing of this attribute was already tracked in dotnet/source-build#2804 which will be one of the next items Ella will be working on.

[mthalman]

How did these did here in the first place? Was it via automation or were they manually added?

[MichaelSimons]

We were previously generating these attributes prior to the refactoring to use GenAPI. These are the few packages that have not been regenerated with the new tooling - tracked with dotnet/source-build#3459

[ellahathaway]

I assume you verified that the assembly attribute is now present? Should we add a test for it (post-merge)?

I did check to verify that the assembly attribute is now present!

[ViktorHofer]

nit: usually you would squash merge such a change. Now with the merge commit, you added your previous changes to the main branch's history (including touching those 600+ projects). Nothing serious but would be good keeping that in mind with your future changes.

[ellahathaway]

/backport to release/8.0

[github-actions]

Started backporting to release/8.0: https://github.com/dotnet/source-build-reference-packages/actions/runs/6536826626