MSTest run fails because source assembly is not trusted

StackOverflow https://stackoverflow.com/questions/201327

  •  03-07-2019
  •  | 
  •  

Question

I just added xUnit to our test project (for the Asserts, we're still using MSTest as the framework) and immediately the test runs refused to execute any of the tests. This is the error message:

Failed to queue test run '{ .... }' Test run deployment issue: The location of the file or directory '...xUnit.dll' is not trusted.

Was it helpful?

Solution

It took me a few tries to find the answer in Google, so I'm putting it here in case anyone else runs into the same problem. A detailed description can be found at this blog posting.

Basically, the fix invovles right-clicking on the dll file (xunit.dll for example) in Windows Explorer, going to Properties, and clicking "Unblock" at the bottom of the tab next to the 'Security' text. It seems that Vista / Windows 2008 will automatically mark assemblies that come from other machines or the internet as unsafe.

As a couple commenters have mentioned, you may also need to restart Visual Studio for this to take effect.

OTHER TIPS

In my team we had the same problem.

Your solution didn't work, but this post by Charles Sterling did help.

We used the following line:

caspol -machine -addgroup 1 -url file://\\server/share/* FullTrust -name DevShare

After having this issue and burning hours trying to get "Unblock" to stick longer than a few minutes and/or figuring out caspol to no avail, I finally found a little tidbit via Google that the assemblies will be blocked again the next time you build or rebuild the project, since they're re-copied from their original source location. (I guess I never noticed that this happened before with references assemblies, but anyway...)

My fix for this was the following:

  1. Copy all the needed DLLs to another spot for safe-keeping

  2. Remove the references in Visual Studio

  3. Physically delete the DLLs in the bin folder

  4. Unblock the DLLs individually in the spot where they were copied off

  5. Add the references back in Visual Studio from the holding spot

Every subsequent build or rebuild worked fine afterward.

Running on an XP machine (even with .NET 3.5 SP1 installed) I was not able to get any of the other solutions listed here to work.

However working from the same post by Charles Sterling that Davy Landman references, I finally succeeded with this variation:

  1. Run the .NET 2.0 Configuration tool (Settings... Control Panel... Administrative Tools... .NET Framework 2.0 Configuration)
  2. Click down to "My Computer ... Runtime Security Policy ... Machine ... Code Groups ... All_Code"
  3. Create a new code group with membership condition of "Zone"="Local Intranet" and assign the permission set "FullTrust"
  4. Restart Visual Studio

After these steps I am able to run tests, including after restarts and rebuilds.

EDIT: as described in this answer, you may need to install the .NET SDK (which is different from the .NET framework) in order to have the .NET 2.0 Configuration tool on your system.

I had the same problem with moq. But would not 'unblock'. Every time I unblocked it, it was still blocked!?!?

I had to unblock the original zip file I downloaded. Then copy the DLL from the zip file again. It work after that.

It may seem really obvious now, but when I was clicking unblock the file was set as read-only.

Only after un-checking that attribute, applying, then selecting unblock did I actually get this working.

Give that a go.

:)

PS: I also deleted all the old dll's in my bin folder, just to make sure Visual Studio wasn't picking up the old one.

I had the same problem with downloaded DLLs blocked by Vista. You need Administrator rights to get the "Unblock" button on the file's Properties. I simply replaced the DLLs with the latest version from source control (TFS) where I had committed them before.

  • Go to file
  • Right click and select Properties
  • On the first Register click on Allow

I also tried opening the file in notepad++ and renaming it. Slightly different approach, but it worked for me. The local file system then think it comes from the same machine.

It's not just the moq.dll that needs to be unblocked. The latest zip file includes an moq.xml and moq.pdb file - referencing the dll copies these other two files to the bin folders as well. If all three have not been unblocked the tests won't run, I found.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top