1

I'm struggling getting some unit tests running and wondering if anyone might have anything insightful.

The setup is that we've got a bunch of referenced DLL's on a server and when I try and execute I get the old

Test Run deployment issue: The location of the file or directory 'c:\source\ProjectName\bin\debug\3rdPartyLibrary.dll' is not trusted.

I've tried the old caspol command:

caspol -m -ag 1.2 -url file:\server\binaries* FullTrust

Which seems to work for everything bar one DLL. I'm currently having to manually change the permissions everytime I do a build of the test project, which is a pain. Anyone have any suggestions? Running a Win7 64bit OS btw.

Jon Seigel
  • 12,251
  • 8
  • 58
  • 92
Ian
  • 33,605
  • 26
  • 118
  • 198

5 Answers5

3

Ian had the key that started the fix for me. I'm attempting to use WatiN on Windows 7 64bit and kept getting the "not trusted" error. Here are the steps I took to fix it.

  1. Close VS.
  2. Delete the WatiN directory from Programs Files (x86)
  3. Navigate to my user directory. Search for and delete WatiN dll's.
  4. Navigate to my project directory. Search for and delete all WatiN dll's.
  5. Re-download WatiN.
  6. Right click on the .zip file and unblock the contents before the copy operation.
  7. Recreate the WatiN directory under the Programs Files (x86) and copy the file from the .zip.

Unless you get the stray WatiN dll's VS will continue to access the untrusted DLL's and drive you nuts.

2

If you go to the dll through Winodws Explorer, right click and go to properties there's an "Unblock" button.

lancscoder
  • 8,658
  • 8
  • 48
  • 68
  • There is, this is how I unlock the file to run a test. But it's not practical doing this after every build. It also doesn't make any difference if I do this to the DLL on the server. – Ian Feb 15 '10 at 09:49
  • Just found these instructions for removing the "Unblcok" option: http://www.petri.co.il/unblock-files-windows-vista.htm (method 3) options are there in Windows 7 too. – lancscoder Feb 15 '10 at 10:00
  • Unfortunately it appeared to work, until I restarted my machine at which point it worked no longer, though the settings have persisted. – Ian Feb 16 '10 at 09:17
1

Are the .dlls in question files downloaded from the internet?

If so, they may be 'blocked' by the OS unless you explicitly unblock them. You can do this by right-clicking the files in question and select Properties, and then click on the Unblock button.

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • Mark, this DLL comes from within a Zip file, downloaded from the internet I believe. As I mentioned in the other answer, unblocking only works on the local file that gets copied, and has to be done on a per-build basis. – Ian Feb 15 '10 at 09:50
  • 1
    Did you Unblock the zip file before you unzipped it? Although I can't really explain it, I've had the same problem and it didn't go away until I unblocked the zip file. If you try this out, remember that you must restart VS before it picks up the file changes, but I guess that on a build server, it always starts from a clean slate. – Mark Seemann Feb 15 '10 at 09:54
  • Mark, no I didn't will give that a try. – Ian Feb 15 '10 at 14:05
  • Unfortunately don't have the zip anymore. Feel like downloading it to trust it to unzip it is not the right approach... – Ian Feb 16 '10 at 09:19
  • I should have added on here at some point, that this was indeed the problem in my case. I had to re-download the zip, to unblock it, then unzip before I could use the DLL in a trusted way. Madness! – Ian May 05 '11 at 08:08
0

You need to download the streams.exe from the below path: http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx

place it in the same folder where you have the problem with the dll and navigate to that path in powershell/command prompt and run the below command: streams -s -d(command prompt) .\streams.exe -s -d "Folder Name"(from powershell)

0

Uncheck 'readonly' before you select 'Unblock' from the properties dialog of the assembly in question. It should stay unblocked if it is not readonly.

Nick
  • 19,198
  • 51
  • 185
  • 312