Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SpecRun creating temp files and not clearing up causing builds to fail #2294

9 of 32 tasks
liamharries opened this issue Feb 5, 2021 · 3 comments
9 of 32 tasks


Copy link

SpecRun creating temp files and not clearing up causing builds to fail

SpecFlow Version:

  • 3.6
  • 3.5
  • 3.4
  • 3.3
  • 3.1
  • 3.0
  • 2.4
  • 2.3
  • 2.2
  • 2.1
  • 2.0
  • 1.9

Used Test Runner

  • SpecFlow+Runner
  • MSTest
  • NUnit
  • Xunit

Version number:

Project Format of the SpecFlow project

  • Classic project format using packages.config
  • Classic project format using <PackageReference> tags
  • Sdk-style project format

.feature.cs files are generated using

  • SpecFlow.Tools.MsBuild.Generation NuGet package
  • SpecFlowSingleFileGenerator custom tool

.NET Framework:

  • >= .NET 4.5
  • before .NET 4.5
  • .NET Core 2.0
  • .NET Core 2.1
  • .NET Core 2.2
  • .NET Core 3.0
  • .NET Core 3.1
  • .NET 5.0

Test Execution Method:

  • Visual Studio Test Explorer

<SpecFlow> Section in app.config or content of specflow.json

Issue Description

Came in this morning to find all overnight test runs failed to generate the specrun report with the below error

The active test run was aborted. Reason: Test host process crashed : Unhandled Exception: System.IO.IOException: The file exists
   at System.IO.Path.GetTempFileName()
   at TechTalk.SpecRun.Framework.Services.ExternalProcessTestRunResultReporter.Report(TestRunResult result, TestProfile testProfile)
   at TechTalk.SpecRun.Framework.Execution.ExecutionEngine.ExecuteTestSuite(TestProfile testProfile, TestRunExecutionConfiguration executionConfiguration, IObjectContainer parentObjectContainer, IExecutionContainerBuilder containerBuilder)
   at TechTalk.SpecRun.VisualStudio.TestAdapter.Execution.SingleSourceTestExecutor.ExecuteTestSuiteSync(IExecutionEngine executionEngine, TestProfile profile, TestRunExecutionConfiguration testRunExecutionConfiguration, IObjectContainer parentObjectContainer)
   at TechTalk.SpecRun.VisualStudio.TestAdapter.Execution.SingleSourceTestExecutor.<>c__DisplayClass23_0.<ExecuteTestSuite>b__1()
   at System.Threading.Thread.ThreadMain_ThreadStart()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

We did some digging and found this post on stack overflow which describes the call to "GetTempFileName()" as the cause of the issue.

We looked on the box and could see lots of folders containing specflow log files

Our IT department has cleared down the %temp% folder on the build agent which has now resolved our issue.

While replacing "GetTempFileName()" with something like a guid name as described in the post would stop the issue from occurring the root cause is that temp files are not being cleaned up in the first place.

Steps to Reproduce

have multiple test runs daily
leave for an extended period of time
observe error once temp folder fills up

Copy link

You learn every day something new about .NET APIs. I wasn't aware of this behavior of GetTempFileName.

Copy link

epresi commented Feb 17, 2021

We released a new version of SpecRun: 3.7.3
It should fix your issue.

@epresi epresi closed this as completed Feb 17, 2021
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

3 participants