search

dotnet / arcade

Tools that provide common build infrastructure for multiple .NET Foundation projects.
MIT License
664 stars 339 forks source link

Re-examine design of SignTool dependencies #6259

Open missymessa opened 3 years ago

missymessa commented 3 years ago

In order to call SignToolTask today, the caller is responsible for setting up and providing the paths to the various dependencies that SignTool requires (e.g. sn.exe, MSBuild.exe, WixToolset, Microbuild Core). This kind of design violates OOP principles, such as encapsulation and abstraction, and forces the caller to be tightly coupled to SignTool. We should investigate the feasibility of moving these dependencies solely into Arcade. If overriding version of these dependencies are necessary for some of the existing functionality, we can provide that, but for the callers of this functionality who are indifferent to the versions used, they should not be expected to manage the dependencies that SignTool needs.

Putting this into the Post Build Signing epic for now, but would be fine if it went into a tech debt epic for Arcade.

chcosta commented 3 years ago

Arcade already manages versions for many of these dependencies. I think we should examine if that management could be moved closer to the implementation and signtool can define its own dependencies while allowing a consumer (like Arcade) to override those versions.