Closed vichor closed 2 months ago
Hi, @vichor! Admittedly this isn't great. It looks like the mixed-case "Sbom" started to appear later in the development process and was never fully implemented. Unfortunately, our team is focusing on other things right now and just don't have the time to commit to "nice to have" items. You could open a PR, if you want, and we'll consider merging it. Probably the preferred option would be to follow the convention of using SBOM for consistency with the file names and the documentation. That's straightforward with Visual Studio's rename ability, which will update all other references at the same time. The tricky bit is that we need to maintain backward compatibility with the old names. So if you were updating the SbomFoo class, you'd do something like this:
#pragma warning disable SA1402 // File may only contain a single type
public class SBOMFoo
#pragma warning restore SA1402 // File may only contain a single type
{
// stuff
}
/// <summary>
/// Provided for backwards compatibility. Please make all changes in the SBOMFoo class
/// </summary>
public class SbomFoo : SBOMFoo
{
// Empty except for non-default constructors
}
You'd also want to have at least 1 unit test for each of the legacy names, probably something along the lines of
[TestMethod]
public void LegacyTypeIsSupported()
{
var legacy = new SbomFoo();
Assert.IsInstanceOfType(legacy, typeof(SBOMFoo));
}
I am following the API reference documentation, specifically the section Self-provided data-based SBOM generator API. There the snippet states to create a new instance of the class SBOMFile, only that this type does not exist.
Looking for SBOMFile in the code finds an SBOMFile.cs file which defines the class SbomFile.
I have checked other elements and the same situation appears, but not for all of them. It seems, thus, there is some inconsistency that would be good to fix:
xxxx may be File, Package, Specification, GenerationResult, Elements that do not present this issue are Reference, Metadata, Relationship, ValidationResult