Debugging System.IO.FileLoadException in Unit Test
<p>For a project I am modernizing, I have a suite of unit tests provided by the application's original developers.  Earlier in my modernizations they were running fully green; however, they've turned red, but mostly all with the same exception:</p>

<p><strong>Exception:</strong></p>

<pre><code>System.IO.FileLoadException: Could not load file or assembly 'MyApp.BusinessLayer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.  Access is denied.

at MyApp.SomeExecutable.SomeClass.SomeMethod(args)
at MyApp.UnitTests.SomeExecutableFixture.CanValidateSomething() in [place of invocation of SomeClass.SomeMethod]
</code></pre>

<p>The exception has no inner exception.</p>

<p>From what I can see, this is happening in any method that refers to something defined in the <code>MyApp.BusinessLayer</code> assembly, which the friendly error message is informing me can't be loaded...apparently due to denied access.</p>

<p>I've tried the following things to gain access to the assembly:</p>

<ol>
<li>Navigate to the assembly in Windows Explorer, and grant myself Full Access.  Had no effect.</li>
<li>Navigate to the containing folder in Windows Explorer and grant myself Full Access.  Still no effect.</li>
<li>Running VS 2015 as Administrator, and re-running the Unit Tests.  No effect.</li>
<li>I decided the situation is insane, so I checked the references in the VS project, but they all point to the assembly that I should be testing against (this is located in the same folder as the UnitTest assembly.)  That can't be it.</li>
<li>Attempted to run <code>fuslogvw.exe</code>, and run the test while that's running to understand the binding process.  No information appeared; it's as if running tests in Visual Studio 2015 is completely invisible to the Fusion Log Viewer!  Even after a restart, the Fusion Log Viewer had no information on what assembly bindings were happening.  (Thanks to @AndrewAu, @CodeCaster)</li>
<li>After a suggestion to use the Process Monitor utility, found that some impersonation was occurring.  I granted SomeDomain\SomeUser permissions to the folder under test; no effect. (Thanks to @DarinDimitrov)</li>
<li>Looking back to the basics, ensured that all assemblies under test are the same .NET version - specifically, .NET 4.6.  They are; that can't be it (Thanks to @Kamo)</li>
<li>After conferring with coworkers, I remembered we've just changed laptops.  I tried loading the code up on my old laptop, where it worked previously.  Still doesn't work there.</li>
<li>While not best practice, in a fit of desperation a coworker suggested referring directly to the business layer DLL, instead of through the business layer's C# project.  That had no effect either (I reverted to the project reference, though.)</li>
<li>Due to the continued insanity of the problem, I reverted my branch to an earlier version that I recall having no problems, and trying the Unit Tests again.  <em>It failed with the same problems.</em>  So, it's not the fault of the code, either.</li>
<li>As I'm using the ReSharper test runner, a coworker remembered the 'Shadow Copy' setting that can cause these sorts of issues.  I disabled the Shadow Copy option for the Unit Test runner...but it also had no effect.</li>
</ol>

<p><strong>Question:</strong> Above and beyond granting myself full access to the folder, what other things can I do to resolve this <code>FileLoadException</code>, especially if this is an access rights problem?  Shouldn't everything I've done have solved an access problem, if this is what this is?</p>