所以我找到了一个适用于 VS 2019 的解决方案，它比我想要的要复杂一些，但对于我的用例来说，有必要解决这个问题。
说明
首先将导致问题的代码移到它自己的函数中，这样您就不会抑制周围代码中的异常，并用 DebuggerStepThrough 属性标记它（或者 DebuggerHidden 也可以）。
[DebuggerStepThrough]
public void ExceptionThrowingFunction()
{
//.. Code that throws exception here
}
那就这样称呼吧
OutsourceException(ExceptionThrowingFunction);
然后选择一个单独的项目（模块），您不关心抑制其中的所有异常，或者专门为此目的创建。重要的是这是一个单独的项目，以便您的主项目仍然可以在此异常类型上中断。就我而言，我已经有一个名为 SharedFunctions 的小型实用程序项目，所以我把它放在那里。代码相当稳定，大部分时间不需要调试。
在一个名为 ExceptionUtils 的类中，我添加了以下函数：
public static T OutsourceException<T>(Func<T> func)
{
T result = default;
try
{
result = func.Invoke();
}
catch { }
return result;
}
public static T OutsourceException<T, Y>(Func<T, Y> func, Y arg)
{
T result = default;
try
{
result = func.Invoke(arg);
}
catch { }
return result;
}
public static void OutsourceException<T>(Action<T> action, T arg)
{
try
{
action.Invoke(arg);
}
catch { }
}
您可能需要添加更多这些，这些仅涵盖您的函数中有 0-1 个参数的基本情况。
最后，当你运行代码时，它仍然会在 Outsource 函数中出现异常，并显示如下消息：
如果您选中底部的复选框（在本例中为“SharedFunctions.dll”），它将添加一条规则，即如果从该程序集中抛出异常，则应忽略该异常。一旦检查了这一点，就应该抑制异常。这种类型的主程序集中的所有其他异常仍将正常中断。
这里发生了什么？
由于 VS 2015 中的更改破坏了 [DebuggerHidden] 和类似属性（请参阅此处另一个答案中链接的 blog post），这些属性现在将异常传递给调用类，而调试器只是在那里中断。如果我们将调用类移动到另一个程序集中，我们可以使用exception conditions system 抑制异常。
为什么不直接修复异常？
某些异常无法从代码中完全删除，例如当您尝试在 UWP 应用程序中访问 Package.Current 时。它总是会在调试器中抛出异常，这只能由微软解决。在这种情况下，另一种解决方案是用#if !DEBUG 将其包围，但在其他情况下这并不实用。