[Feature] Introduce a source-only Microsoft.Toolkit.Diagnostics NuGet package about dotnet

Hello, 'Sergio0694! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[michael-hawker]

@Sergio0694 would it make sense to keep the binaries in the Microsoft.Toolkit or a Microsoft.Toolkit.Diagnostics package, but then have a separate Microsoft.Toolkit.Diagnostics.Sources package like the examples in the article you shared? That'd help if our other packages start using them as they wouldn't be duplicating the source for each package using it, eh?

[Sergio0694]

@michael-hawker I'd say that regardless of the proposal for a source-only package, the idea of moving the Guard and ThrowHelper APIs to a separate, standalone Microsoft.Toolkit.Diagnostics package sounds great to me anyway 😄
That'd still mean that consumers would have more fine grained control over what APIs they're using in their apps, sure!

As for the bit about duplicating the sources in the other Toolkit projects, not sure that that'd be an issue, since we can just use [assembly: InternalsVisibleTo("...")] so that all the other projects would be able to use a single "copy" of all those APIs that they have access to through the base/diagnostics package. Of course that also depends on how we actually want to set that up though, as in, we might also just choose to depend on the .Diagnostics package too and consumers of the other packages would automatically inherit those APIs as well (like they do today). That depends on how we want to structure this, since those APIs would still be included in the actual binaries anyway (as other packages do use them).

As for the Microsoft.Toolkit.Diagnostics.Sources package, that name sounds perfect and it would convey the difference pretty clearly (so that other people would immediately know they won't actually take dependencies at runtime), so that sounds great! 👍

[yoshiask]

Even if the package only contained the Guard and ThrowHelper APIs, those would still then be visible to consumers of those libraries, as indirect dependencies...

I've run into an issue related to this in the wild. One of my dependencies still uses the Microsoft.Toolkit.* packages, while my project uses the newer CommunityToolkit.* packages. The result is that my project has the same functionality under two different namespaces.