Consider publishing Microsoft.Extensions.Logging.Testing to nuget.org

[npnelson]

Many of my tests make use of the NullLogger defined in:

https://github.com/aspnet/Logging/tree/dev/src/Microsoft.Extensions.Logging.Testing

As far as I can tell, this package isn't published to nuget.org, so I find myself cutting and pasting it and then possibly updating it with every AspNetCore release.

[NKnusperer]

Please do this, TestLogger is also helpful if you need a spy for unit testing.
The only thing to consider is LogValuesAssert.cs which depends on Xunit, this should be removed to stay independent from the testing framework.

[npnelson]

I recently started a new project and found myself wishing (again) that Microsoft.Extensions.Logging.Testing was available on the main nuget feed.

Are there any downsides to publishing this package? There is a lot of good stuff in there. Maybe you could make it available in 1.1.0-preview1?

Removing the dependency on xunit.assert would ideal, but even if you don't have an easy way to remove that dependency, I think the community would be better off with the package published to the main nuget feed.

[muratg]

cc @DamianEdwards @Eilon

[muratg]

@DamianEdwards thoughts?

[Eilon]

If we ship it we need to support it, can't make breaking changes, etc. That's pretty much the concern I have. As it stands right now we can freely add/remove/break/change whatever we need, whenever we need.

Any thoughts on how to mitigate these concerns?

[thoean]

• What about shipping it with a -alpha tag?
• Don't version solve for allowing breaking changes?
• I'm fully supporting a ship-early-and-get-feedback mentality, and leverage alpha, beta or preview tags.

[Eilon]

We could certainly just always keep it as -alpha though that's a bit odd, isn't it?

And versions do have answers for breaking changes, but the question is do we want to have to worry about maintaining that whenever we do breaking changes. As it stands right now we just "do whatever we want" and don't worry about versions.

[npnelson]

Maybe you could give it a -UseAtYourOwnRisk tag or something like that? I understand and embrace the desire for Microsoft to do whatever it wants with this package.

Overall, I think the developer community would be better served by releasing this package, while understanding the "use at your own risk" caveat.

[roji]

Two suggestions if you do decide to publish this:

• Consider reimplementing TestLoggerFactory as a provider, which could then be added alongside console to allow users to print logging from tests.
• Consider emitting events from TestSink, which would allow tests to subscribe to them and handle certain events happening.

[ItielBeeri]

We could certainly just always keep it as -alpha though that's a bit odd, isn't it?

Gmail was in beta more than five years.

[niemyjski]

Any updates on this?

[Eilon]

BTW all the NullLoggerXyz stuff is now in a shipping package, such as https://github.com/aspnet/Logging/blob/dev/src/Microsoft.Extensions.Logging.Abstractions/NullLogger.cs

But the TestLogger stuff is not, and at this time we still don't have plans to change that.

[twenzel]

Any progress on this?

[offbeatful]

+1
This will be helpful.

Thanks!

[takekazuomi]

+1
This will be helpful.

[WadeOne]

+1
This will really be helpful.

[martincostello]

I just stumbled across this while looking at something else, and I recently published an alpha of a package that does something similar.

In lieu of this being published more generally, people might find this of use:

https://github.com/martincostello/xunit-logging

[muratg]

We won't be publishing this package.

[crupest]

After searching for this package on nuget for about several minutes, I finally got here.
I think I really need this package like some of others above.
Though it may look strange to comment in closed thread, I still want to vote on it hoping one day it will be shipped on nuget. 😅

[maciejw]

things like xunit itesthelperoutput and microsoft.extensions.logging integration is very useful... maybe you reconsider... :)

support on some parts should not be difficult, remember also, you can tag something #need help :)

[muratg]

cc @anurse

[analogrelay]

We're not really in a position to support those as "official products", which is why we don't publish them to NuGet. You're always welcome to take the code and clone it (under the, quite permissive, terms of the license), but publishing it as a library on NuGet means backing it as a full on Microsoft product.

support on some parts should not be difficult, remember also, you can tag something #need help :)

Everything comes with a cost, even community contributions. We can't rely on community contributions to fix critical issues in our products, or security issues. We certainly welcome contributions, but we can't fulfill the support commitment we make to our customers without resources.

Also, these components are tightly coupled in to how we build ASP.NET Core and Extensions. If we release them as NuGet packages we have to treat them like public products and avoid breaking changes. That restricts our ability to add things we need to build ASP.NET Core.

We'll certainly keep evaluating that decision as more input comes in, but right now it doesn't feel like the benefit of this (given that the code is fairly simple, very available, and can be easily copied) is worth the cost in supporting it as a product right now.

I'm glad people are finding these useful outside of our intended scenarios, but I don't expect these to be any more than just internal (open-source!) libraries that we don't ship to NuGet.

[alefranz]

FYI as I often use bits of this, I've now packaged it alongside some helpers to simplify the consumption in simple scenarios. If anyone else needs it, it is called MELT.

I've excluded the xUnit output helper as there is already a package for it.