RFC rewrite of tool as msbuild task

[coderpatros]

Having looked into this issue https://github.com/CycloneDX/cyclonedx-dotnet/issues/399, I've come to the conclusion that the only way to achieve real accuracy is to generate the BOM from within the msbuild process.

This is a significant change. Not just in terms of effort, but also how the tool will be used. Instead of being run as a command line tool it will need to be added as a build time dependency to the project.

I'd be interested in hearing from anyone who has an opinion on how this change should be managed. Or if you think there is another way.

The approach I'm planning is to create a new .NET msbuild tool, and "deprecate" this one.

Although it could cause some confusion at first, it will make it easier to maintain some level of support for the current tool. Which will probably be required for some time for older .NET projects.

[asymmetricblue]

I've been playing around with calling MSBuild libraries directly, and through Buildalyzer in order to make progress on #79, and I think I could get it to work within the confines of a tool like this, or as a msbuild task.

However, structurally, it is a very different thing, and will require significant refactoring to get there. It also takes a dependency on part of the SDK in order to return results, it cannot operate solely via the runtime anymore.

Depending how it is done, you will also see a much larger dependency tree come out of this. You might consider that good or bad depending on your perspective. e.g. a package reference to netstandard.dll will expand out to something like 114 items. This might necessitate different parameters than today.

I'd be happy to collaborate either way to get this done, though I am beginning to think that your approach of building a new tool, either as a major vNext of this, or a msbuild task is a reasonable way to go.

[github-actions[bot]]

This issue is stale because it has been open for 3 months with no activity.