coverlet.collector produces empty report when BuilGenerator is referenced

[jvmlet]

coverlet.collector produces empty report when BuilGenerator is referenced in the project

[MelGrubb]

Could you provide any more information? Is coverlet running as part of a build pipeline? Are there any complaints in the build output? Surely it's complaining about something.

[jvmlet]

Unfortunately, no complains at all. Simply outputs empty xml file. Have a look at referenced issue, coverlet devs suggested you to generate g.cs files...

[MelGrubb]

Ah, the generated files use the longer form foo.generated.cs. I've considered using the shorter 'g', but not everyone knows what that means. From the link, it sounds like the issue has been resolved on their side though.

[jvmlet]

g.cs is the agreed convention, and, as you see has impact

[MelGrubb]

Both are in widespread use. Coverlet should expect and support both. For example, see the "important" section here: https://learn.microsoft.com/en-us/dotnet/csharp/nullable-migration-strategies#plan-your-migration

I actually like the shorter version myself, and may change, but I've seen both in the wild.

[jvmlet]

FYI https://github.com/mcintyre321/OneOf/issues/107

[MelGrubb]

Oh, I get that emitting ".g.cs" would solve the Coverlet problem, but asking everyone else to change their projects to make Coverlet happy doesn't seem like the correct solution. Coverlet needs to understand that there are multiple different possible extensions in use (.g.cs, .generated.cs, .designer.cs) and support them all. I know of several projects that quite definitely use ".generated.cs". That is outside my influence, and the idea that Coverlet is simply ignoring this is actually kind of a problem.

I can update the builder to emit as ".g.cs" since that seems to be more prevalent out in the wild these days. I don't think it would have any negative impact since the files aren't physically left behind, and therefore it shouldn't affect source control or result in duplicate files for users, at least not by default. Perhaps it should be controllable via the marker attribute in case someone depends on the older naming for some reason.

[jvmlet]

Thanks a lot @MelGrubb

[MelGrubb]

It looks like Coverlet does support additional extensions now. https://github.com/coverlet-coverage/coverlet/pull/1392/files#diff-be914c2ef40b4434ccb0927c453da5f7f2a4f828d601367f585bd7284349ba85L486-L490 Unfortunately, that was merged in last November, but the latest release is from October, and I don't see any indication of when the next version is expected. Murphy's law clearly states that it will be the day after I put out a change to ".g.cs", though.

[jvmlet]

Yes, I checked your Build Generator with coverlet snapshot version, works fine, but no estimation for release date...

[MelGrubb]

Not ready to close this yet. My whole pipeline needs to be updated. I'll close manually once I have a successful publish up.

[MelGrubb]

The pipeline still needs work, but it looks like it got a build out, so I'm closing this again.