Failed to queue test run [...] Test run Deployment issue: The location of the file or directory [..] is not trusted

I'm currecntly developping a sample orders management solution using VB.NET 2008, NHibernate, FluentNHibernate and Linq for NHibernate.

On runtime, I get the following error:

Failed to queue test run [...] Test run deployment issue : The location of the file or directory 'C:\Open\Projects\Examples[..]\FluentNHibernate.dll' is not trusted.

And I get the same with NHibernate.Linq.dll

Failed to queue test run [...] Test run deployment issue : The location of the file or directory 'C:\Open\Projects\Examples[..]\NHibernate.Linq.dll' is not trusted.

Both assemblies are referenced into my tests project. It is only when trying to unit test my DAL that it has begun to do these tricky errors.

I have read something about running

"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\caspol -machine -addgroup All_Code -url file://comdumap:/* FullTrust -n DevelopmentMappedDrive"

(it's in French, but really just a few words easy to translate with Google Language Tools.)

I may provide you with any further helpful d开发者_JS百科etails if necessary. I don't know much what could be useful, so I prefer waiting for your inquiries if any.

EDIT 1: I found another reference stating the error solution like this: Test Run Deployment Issue

It seems that after unblocking through Windows Explorer, this might allow these files to be deployed in order to perform the tests. Thus, I keep having this error and my tests won't launch.

Thanks for any help!

Reposted as answer and elaborated.

The fact that you're running unit test code that fails because of untrusted location is a sign that you're not doing unit testing, you're doing integration testing. This is brittle and prone to other problems, so I would try to avoid doing that as much as possible.

Unit testing should test small pieces of logic, units of code, like classes, methods, etc.

The second you pull in code that does one of the following, you're likely to have problems:

• Code that requires a database
• Code that requires a file (or file access)
• Code that talks to some external system (like a COM object, a web service, anything over a network)

For instance, what happens if:

• You run the unit tests on your own machine, but at home? Do you have access to the same systems?
• The database changes?
• The database is moved to a different server to free up some space?
• The disk is full?
• The network is down, or having hickups?

All of these things, and hundreds more, will cause your unit tests to fail, because not only are you testing the logic that sits on the other end of those connection paths, but you're also testing that the connection path works.

This causes your tests to be brittle, and prone to error.

When a test fail, you will always want to say "ok, we must've done something to break the code". You never want to hear this "argh, this test fails all the time, just leave it, it's probably the server again".

The reason your unit tests fails related to your question is that because the code is required to talk to an outside system (file, database, web server, network device), it requires elevated trust. If it only runs normal code, it doesn't require elevated trust, so your problem is a dead giveaway that you have such tests.

These tests are called integration tests, because not only do they test code, but they test how well your code integrates with the outside world as well.

I would try to remove those parts of the test, perhaps by refactoring them out, so that you can replace them with test systems in your unit tests.

For instance:

• If your code needs to write to a file, separate out the code to write to a file to a new class, in a method like WriteToFile, wrap the class in an interface, and give the object to the logic code as a parameter. Then, in your unit tests, create a new class implementing the same interface, but that just records that the method was called, and not try to write anything to a file. This way you can test that "the method that was supposed to write to a file was actually called with the right data", and not "the file was successfully written".

For database and web servers and similar, you can do the same thing.

Finally, note that of course at some point you might want to actually run tests that ensures the file actually ends up on disk. However, you should separate all those tests out into their own project so that if they break, you know it's an integration test, all the unit tests should be able to run fine.

I succeeded to deploy the test run following the steps in this solution.

Read your file or directory path carefuly, as I myself mistaken and thought this solution wasn't applicable for my case.