looking for appsettings.json

With a recent upgrade (and I can’t tell you whether we are talking Moq. MSTest, .NET Core or Visual Studio)

I am seeing a lot of my tests fail with:

Test method MyTestMethod threw exception: 
System.IO.FileNotFoundException: The configuration file 'appsettings.json' was not found and is not optional. The expected physical path was 'D:\....\my project\TestResults\Deploy_MarkHeaton 20230114T084906\Out\appsettings.json'.

  Stack Trace: 
FileConfigurationProvider.Load(Boolean reload)
ConfigurationRoot.ctor(IList`1 providers)
ConfigurationBuilder.Build()
ActionFilterAttributeTest.ExecuteOnActionExecutingTest(String testName, IHeaderDictionary headerDictionary, IRequestCookieCollection cookieCollection, Type resultType) line 127
BasicAuthenticationAttributeTest.TestBasicAuthenticationAttributeNoUser() line 27

Obviously it is expecting an appsettings.json file in the OUT directory and that is not there. Google suggests issues with active project context with this sort of error.

Any thoughts?

[MCFHTAGENTS]

ok - the issue here is my application, which is a .NET Core website, expects the current directory to be the directory the app is installed into (as do some of the MS libraries I use) and the test framework is setting it to the ‘out’ directory and so all the relative paths break and it also can’t find appsettings.json.

Adding this

        [ClassInitialize]
        public static void Setup(TestContext ctx)
        {
            //Work around added for MSTest
            var dirName = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
            Directory.SetCurrentDirectory(dirName);
        }

keeps it working as I would expect

[Evangelink]

I just did investigate your reproducer and this is a breaking change behaviour documented (https://github.com/microsoft/testfx/blob/main/docs/Changelog.md#300---2022-12-06), in particular the entry [breaking change] Unify DeploymentDirectory location across target frameworks https://github.com/microsoft/testfx/pull/1414. There was a long standing bug where the DeploymentDirectory was not pointing to the correct directory. But because of the time it took to fix the issue, a lot of people got time to rely on this behaviour.

There is nothing better but updating your code that we could recommend.