How to Disable the NuGet Audit Check in Visual Studio 17.12+

Together with .Net 9 we got a new Visual Studio version. Not a Visual Studio 2025 or something that signals the significance of the version change. No, we got the small step of 17.11 to 17.12 and may give not much notice to all the changes – and they are big.

Good idea, terrible execution

With 17.12 we not only get a new approach to vulnerability checks in NuGet, but we also get an epic cluster fuck. The idea was great: show the developers that there are vulnerabilities in their packages so that they can fix them as soon as possible. It would even work if it was not for these massive problems:

1. These warnings block the build when you set "all" at the "Treat warnings as errors" option.
2. It warns the same way about transient packages (packages that are used by the packages we declare) as it does with directly referenced packages. One we can control, the others not.
3. Visual Studio does not support us in any way to fix the vulnerable versions. Quite the opposite, it stands in our way to make the fixes. The NuGet update dialog pops up and hides immediately so that we have no clue why the action failed. And fixing the numbers by hand is cumbersome.
4. Changing the version of transient packages brings new problems if they had changes in minor versions.

If you now update to the new minor version of Visual Studio, you can turn a project that works great and has no known vulnerabilities into a project with hundreds of errors that no longer builds and that you cannot fix with a reasonable amount of work:

To no one’s surprise, most of the documented ways to fix the problem do not work or are not doable – like changing all project.json files.

Disable the audit check completely

There is one option that works and that let us keep working. Create a Directory.Build.props in the root of your project and add this content to it:

<Project>
   <PropertyGroup>
        <NuGetAudit>false</NuGetAudit>
    </PropertyGroup>
</Project>

You may need to restart Visual Studio, but then you can build your application without any further fixes.

But now we have a new problem: we do not get warnings about vulnerable packages.

Find the vulnerabilities

We now need to do extra work to get the list of vulnerable packages, what adds the risk of ignoring that step. The best answer I have at the moment is to create a repeating entry in your calendar to remind you to check for vulnerable packages. We then can switch in the code above from false to true and do the checks on our own.

Conclusion

The idea was great, but the delivery fell short, and we are left with a mess that we now need to clean up. Even worse, the execution was so bad that the mitigation strategies we have will block the benefits in the future. I hope Microsoft fixes the problem soon and in a way that takes less effort than to disable the feature entirely.