TFS Build fails with "cannot access file *FakeTypesCache"

4
votes

since a few days we are experiencing issues with our TFS build. We use Microsoft Shims/Fakes for some of our unit tests and so far we had no issues with it. But lately the UnitTest Step fails on the with the following error: The following happens every once in a while:

2016-07-01T06:40:25.3532321Z ##[error]Error: System.IO.IOException: The process cannot access the file 'D:\Builds\Agent\87a4a39e\...\bin\Debug\mscorlib.4.0.0.0.Fakes.FakedTypesCache' because it is being used by another process.

2016-07-01T06:40:25.3532321Z ##[error]   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

2016-07-01T06:40:25.3532321Z ##[error]   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)

2016-07-01T06:40:25.3532321Z ##[error]   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)

2016-07-01T06:40:25.3532321Z ##[error]   at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize, Boolean checkHost)

2016-07-01T06:40:25.3532321Z ##[error]   at System.IO.StreamReader..ctor(String path)

2016-07-01T06:40:25.3532321Z ##[error]   at Microsoft.VisualStudio.TraceCollector.FakesAssemblyReflector.LoadShimTypesFromCache(String fakedTypesCacheFilePath)

2016-07-01T06:40:25.3532321Z ##[error]   at Microsoft.VisualStudio.TraceCollector.FakesAssemblyReflector.ReflectShimTypes(String fakesAssemblyFullPath)

2016-07-01T06:40:25.3532321Z ##[error]   at Microsoft.VisualStudio.TraceCollector.UnitTestIsolationDataCollector.PopulateCollectionPlan(_CollectionPlan plan, XmlElement settings)

2016-07-01T06:40:25.3532321Z ##[error]   at Microsoft.VisualStudio.TraceCollector.UnitTestIsolationDataCollector.OnSecondCollectorToInitialize(_CollectionPlan plan, XmlElement configurationElement)

2016-07-01T06:40:25.3532321Z ##[error]   at Microsoft.VisualStudio.TraceCollector.CommonDataCollector.OnInitialize(XmlElement configurationElement)

2016-07-01T06:40:25.3532321Z ##[error]   at Microsoft.VisualStudio.TraceCollector.BaseDataCollector.InternalConstruct(XmlElement configurationElement, IDataCollectionEvents events, IDataCollectionSink dataSink, IDataCollectionLogger logger, IDataCollectionAgentContext agentContext)

2016-07-01T06:40:25.3532321Z ##[error]   at Microsoft.VisualStudio.TraceCollector.BaseDataCollector.Initialize(XmlElement configurationElement, DataCollectionEvents events, DataCollectionSink dataSink, DataCollectionLogger logger, DataCollectionEnvironmentContext environmentContext)

2016-07-01T06:40:25.3532321Z ##[error]   at WEX.TestExecution.DataCollectorTestMode.Initialize(ITestModeSettings settings, ICallbackRegistrar callbackRegistrar)

2016-07-01T06:40:25.3532321Z ##[error]

I'm not sure if it has to do something with our code coverage (because the stack trace mentions this datacollector). We use a runsettings file to in-/exclude certain things from the code coverage.

On the build server we have an installed Visual Studio 2015 Update 3 (but the problem occured as well with Update 2) and the TFS is version 2015 RTM.

The file that is apparently locked is not always the same, but it is always one of the "FakeTypeCaches".

Any help would be appreciated

Thanks

Edit

It seems that the problem was caused by running the unit tests in parallel (I think the option is available since VS 2015 Update 1). Running them not in parallel seems to have fixed the problem, but sadly running our tests now take considerably longer to run. Especially for our CI build this is not ideal as we would like to get the feedback as soon as possible. If we could only run the tests that use Faked/Stubbed classes sequentially that would be ideal, but as of know I don't know how one would achieve this.

Our solution now to solve this problem is to mark all tests that use Fakes/Shims in any way with a TestCategory: [TestCategory("Sequential")]

On the build server we have defined two unit test steps, the first filters for all categories except "Sequential" and is run in parallel, the second then runs the "Sequential"s not in parallel.

3
c#visual-studiotfs
Did you have multiple build agents on you build server? What's the result if you try to build this with another build agent? - PatrickLu-MSFT
Hi, we only have one build agent on the build server. - huserben

3 Answers

0
votes

Based on the error message, it seems that other process holding that file. Try to use this tool to determine which file exactly is beeing locked by which process. Then stop the process when the building is in progress.

0
votes

This is a known issue fixed in Update for Microsoft Visual Studio 2015 Update 2 (KB3151378).

You should just grab the latest update for Visual Studio, which at the time of this answer is: Visual Studio 2015 Update 3

0
votes

we are on TFS2015 Update3 On-Promise, we have the same issue when run unit tests in parallel. Our short term solution is disabled Repository clean option, and only use MSBuild clean,so those fakes cache file won't be cleaned. Seems the error only happens if multiple tests trying to create the fakes cache files at the same time.

However with disabling the Repository clean option, we are also experiencing some other random annoying issues. :(.

Kindly let me know if you have figure out a better way to avoid the issue. Thanks, Angel