It turns out that when you include such a file, the ASP.NET Code Coverage collection activates. This in turn needs to reset the application pool to attach itself to it. (Hence the reference to IIS7Resetter
). Turning off the ASP.NET code Coverage gathering features resolves the error:
<?xml version="1.0" encoding="utf-8"?>
<!-- File name extension must be .runsettings -->
<RunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<!-- Include the below line in your .runsettings file-->
<CollectAspDotNet>False</CollectAspDotNet>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
But that didn't explain what was going wrong. Since the Stack Trace hints towards the App Pool user, we started investigating that. Turns out that setting the App Pool to LocalSystem
or NetworkService
actually resolves the issue as well. We had it configured to .\SomeLocalUser
. Some more tinkering found the root cause, the code used to get the identity of the Application pool doesn't like the short notation. actually entering the machine name fixes it completely: MachineName\SomeLocaluser
. I suspect that this is an actual bug in Visual studio and that it'll be fixed in a future timeframe, but until then these two options might help someone else figure out what's going wrong as well.
Note: It's probably best to set the CollectAspDotNet
option to False
by default anyway. As long as you're not running integration tests or CodedUI tests against your server, it speeds up your test run considerably.
See also: