Failed to Load RunSettings File

[kakins]

Installed product versions

• Visual Studio: 2022 Professional
• This extension: 1.1.180

Description

I noticed that occasionally unit tests would just fail to run, even after executing via the VS UI. I then noticed an exception being thrown in the output window...

System.InvalidOperationException: Failed to load RunSettings file: 'my-test-project-path\bin\Debug\net6.0\fine-code-coverage\coverage-tool-output\KitchenIntegrations.Configuration.IntegrationStatus.UnitTests-fcc-mscodecoverage-generated.runsettings'. Please check if the file exists and is valid.
   at Microsoft.VisualStudio.TestWindow.Controller.RunsettingsProvider.GenerateTestRunSettings(RunSettingConfigurationInfoState infoState, String runSettingsFilePath, IUserRunSettings runsettings, IEnumerable`1 runSettingsServices, IEnumerable`1 customSettingsImporters, RequestConfiguration requestConfiguration, ITestWindowTelemetry telemetryService)
   at Microsoft.VisualStudio.TestWindow.Core.Client.ContainerRunSettingsProvider.<GetRunConfigSettingsMapAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Core.Client.ContainerRunSettingsProvider.<GetRunSelectedSettingsMapAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.TestRunRequest.<PerformRunAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Logging.ILoggerExtensions.<CallWithCatchAsync>d__11`1.MoveNext()

Steps to recreate

Current behavior

Will sometimes cause test to fail to run in visual studio

Expected behavior

Allow tests to run in visual studio

[tonyhallett]

For Ms code coverage FCC will generate a runsettings file and add an msbuild property to the test proj file.
When completed it attempts to delete this build property.

Please can you check your proj file to see if the RunSettingsFilePath property is present or not.

[kakins]

@tonyhallett Sorry for the severely delayed response on this. Yes I see where the entry is made in the csproj file, and it attempts to do this with every test run it seems. However, the problem is still intermittent.

Before the failure, it actually creates the csproj entry, and doesn't delete it because an exception is thrown. Then the next time I run my tests, they execute and afterwards the csproj entry is deleted. So every other test run fails for me.

It's almost like the tests initially try to run before the csproj is updated.

Also, I should note this appears to be happening with some projects and not others, which is very strange. Both unit tests projects are .NET 6 with the same packages installed.

[bb-avi]

FYI: I've found this can occur when the file path to the generated *.runsettings file is longer than 260 characters. This isn't too difficult to make happen since FCC requires at least 96? characters for its naming scheme:
bin\debug\net7.0\fine-code-coverage\coverage-tool-output\<assembly-name>-fcc-mscodecoverage-generated.runsettings

[tonyhallett]

The latest release fixes scenarios where the runsettings entry in the project file is not removed. The removal should result in no test explorer exception for a missing runsettings file. Please open a new issue if this is not the case.

The number of characters used by fcc for directories and files names can be looked at a later date. ( FCC does need to differentiate the runsettings files as there may be many in the same directory. We could use the project guid if this is shorter than the project name )