在深入研究了ApplicationSettingsBase和相关的类之后，我想出了这个解决方案，虽然不是特别漂亮，但它确实完成了任务。
代码生成的设置类在类库项目内部，并且单元测试项目必须可以访问该类。请将[assembly: InternalsVisibleTo("UnitTestAssemblyName")]特性添加到类库项目中的AssemblyInfo.cs。
当访问值时，设置从设置类的属性延迟加载。第一步是对设置执行“虚拟”读取以强制此延迟加载。当单元测试时，您希望避免在一个测试中更改的设置值影响另一个测试，因此有必要在延迟加载之前“重置”设置。这可以使用Reload()方法完成。此代码位于测试初始化方法中：

Settings.Default.Reload();
var dummy = Settings.Default.MySetting1;

底层的值现在已经存在了，并且可以在每个测试方法中设置。记住使用正确的类型，因为代码生成的getter将执行一个类型转换：

Settings.Default.PropertyValues["MyStringSetting1"].PropertyValue = "Foobar";
Settings.Default.PropertyValues["MyDoubleSetting2"].PropertyValue = 3.1416D;

我会在Settings类的周围创建一个 Package 类，然后传递这个 Package 类，这样你就可以轻松地去掉你的设置类了。
我能想到的唯一的另一件事是让你的设置文件实现一个反映你所有设置的接口，这是一个更轻量级和更容易模仿的选项。这对调用者来说没有太大的不同，但是当你添加新设置时，你会有更少的管道要做。
这两种方法都不是很好，而且对于自动生成的代码来说，必须这样做是一件痛苦的事情，但就我所知，如果您真的想删除对设置文件的依赖，这似乎就是我们所坚持的。
例如，对于包含字符串应用程序设置和int用户设置的设置文件：

internal sealed partial class Settings : IMySettings {

    /*
     * here be auto-generate code (and dragons!)
     */
}

internal interface IMySettings
{
    string ApplicationSetting
    {
        get;
    }

    string UserSetting
    {
        get;
        set;
    }
}

所以您的设置可能有所不同，但对我来说，使用Moq模拟Microsoft.Extensions.Configuration.IConfiguration是有效的，如下所示：

public void UnitTestName() {
//arrange
configMock = new Mock<IConfiguration>();
configMock.Setup(x => x.["keyName"]).Returns("value");
//assert
...
}