Skip to content

Unexpected empty.nupkg in output directory #1714

Closed

Description

@TomW-Skyline

Describe the bug

Verify.MSTest version 31.15.0 adds an empty.nupkg file in the output directory of our unit test projects.
The problem is that this file is being picked up by our CICD to be pushed to a NuGet registry.
Is there a way to avoid that the "EmptyFiles" directory is being created?

Activity

  1. gsolic commented on Apr 22, 2026

    @gsolic

    We also have the same issue with version 31.16.1.

  2. SimonCropp commented on Apr 23, 2026

    @SimonCropp
    Member

    @gsolic can u provide a zipped solution that reproduces the problem.

  3. gsolic commented on Apr 23, 2026

    @gsolic

    You can use the NUnitNugetUsage project as a reference. From the repository root, run:

    dotnet test -c Release ".\usages\NUnitNugetUsage\NUnitNugetUsage.csproj"

    After execution, you will notice that the file .\usages\NUnitNugetUsage\bin\Release\net10.0\EmptyFiles\archive\empty.nupkg is generated and subsequently picked up by our CI pipeline.

    My question is: what is the purpose of the EmptyFiles directory in the output, and is there a way to prevent it from being created?

  4. SimonCropp commented on Apr 24, 2026

    @SimonCropp
    Member

    can u try 31.16.2

  5. gsolic commented on Apr 24, 2026

    @gsolic

    EmptyFiles is still in the output directory on 31.16.2 with dotnet 10.0.107

  6. SimonCropp commented on Apr 24, 2026

    @SimonCropp
    Member

    did u manually delete your bin and obj directories?

  7. gsolic commented on Apr 24, 2026

    @gsolic

    yes, i did

  8. SimonCropp commented on Apr 24, 2026

    @SimonCropp
    Member

    in that case i need a minimal repro since the the nunit usage no longer reproduces it

    Image
  9. gsolic commented on Apr 24, 2026

    @gsolic

    It turns out this was my mistake. I checked out the 31.16.2 tag and ran the NUnitNugetUsage test, but only just realized that in this tag the NUnitNugetUsage.csproj still references 31.16.1. I had assumed it was using a direct project reference instead.

    Sorry for the confusion. It looks like 31.16.2 no longer produces the EmptyFiles issue. Thanks for your help!

  10. SimonCropp commented on Apr 24, 2026

    @SimonCropp
    Member

    @gsolic good to hear

  11. added this to the 31.16.2 milestone on Apr 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions