5

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:

Exception:

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]

The exception has no inner exception.

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

I've tried the following things to gain access to the assembly:

  1. Navigate to the assembly in Windows Explorer, and grant myself Full Access. Had no effect.
  2. Navigate to the containing folder in Windows Explorer and grant myself Full Access. Still no effect.
  3. Running VS 2015 as Administrator, and re-running the Unit Tests. No effect.
  4. 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.
  5. Attempted to run fuslogvw.exe, 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)
  6. 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)
  7. 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)
  8. 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.
  9. 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.)
  10. 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. It failed with the same problems. So, it's not the fault of the code, either.
  11. 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.

Question: Above and beyond granting myself full access to the folder, what other things can I do to resolve this FileLoadException, 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?

Andrew Gray
  • 3,756
  • 3
  • 39
  • 75
  • 1
    Try using the Fusion Log Viewer (fuslogvw.exe) to understand the assembly loading process? – Andrew Au Jan 04 '16 at 16:55
  • A runnable repro can be very helpful – Andrew Au Jan 04 '16 at 16:55
  • 1
    Could you provide some information where this failing assembly is located? In the same folder as dlls that you are going to test? – Marcin Iwanowski Jan 04 '16 at 16:59
  • 1
    Check if some process hasn't locked this assembly. You could use [`Process Explorer`](https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) tool to see which processes have opened handles to it. – Darin Dimitrov Jan 04 '16 at 17:00
  • @MarcinIwanowski - Already done. The Unit Test project and all assemblies under test are being built to the same directory. I amended Thing I've Tried #4 with that information, though. Good suggestion. – Andrew Gray Jan 04 '16 at 17:02
  • @DarinDimitrov - Good suggestion; Process Explorer revealed some impersonation was going on, but still the tests fail for the same reason. I'm still using `procmon` to look for locks like you're talking about as well. – Andrew Gray Jan 04 '16 at 17:29
  • 1
    @AndrewGray Are you sure you are targeting the same .NET version in you tests and DLL? – kamil-mrzyglod Jan 04 '16 at 17:31
  • @Kamo - Yes, that was actually the very *first* thing I modernized (originally the app was .NET 2.0.) Still, I'll add it to the List of Things I've Tried and verify it one more time just to be sure. – Andrew Gray Jan 04 '16 at 17:34
  • 1
    You need to restart Visual Studio after enabling fusion logging. – CodeCaster Jan 04 '16 at 17:41
  • @CodeCaster - No effect. :( Still no fusion logs for me. I was sure to hit Refresh as well. – Andrew Gray Jan 04 '16 at 17:47
  • @AndrewGray What runner are you using for your unit tests? Do you have impersonation enabled in your config? – kamil-mrzyglod Jan 04 '16 at 18:35
  • @Kamo - I'm using NUnit for my unit tests, but I'm executing the tests from VS with the ReSharper test runner. I'm not using ASP.NET impersonation in the config file, as these tests aren't testing against a Web Site, Web API, or Web Service project. – Andrew Gray Jan 04 '16 at 18:51

0 Answers0