API restriction: The assembly 'file:///C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.Visua

Question

All of sudden we started getting this error when trying to build one of the test project...does anyone know what this is about?  I checked with source control and found no differences since last time tests ran, I reloaded Visual Studio.

Thanks

API restriction: The assembly 'file:///C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.

Answer 1

Here is more information.

 

This occurs when I just build the unit test project for one particular project.  For whatever reason it seems like an MSBuild task is being fired, but I find none in the pre or post build events:

 

C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamTest\Microsoft.TeamTest.targets(14,5): error : API restriction: The assembly 'file:///C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.

 

Can I take this target out?  Any idea why MSBuild is firing when building a Test project?

 

Answer 2

And some more info:

If I take out the target, Visual Studio failed to build the project because it said all my references to my accessor were invalid - that I needed to add a reference.  So I re-added the target and was back to my API restriction.  So I took out the reference to Visual Studio unit testing framework and restarted Visual Studio and no it failed to build because of my references to the unit testing framework, which I expected; but then I re-added the reference, and without shutting down, tried to rebuild the project.

This time the project built without a problem.  WTF?

So I close down Visual Studio, and re-open...API reference is back.  To repeat the above theory, I remove the reference to Unit testing framework.  Tried to rebuild...not 'missing reference' error; just the API thing.  I close down VS and re-open project.

Once I re-open, again project has missing reference error to the unit testing framework (no API error), I add the reference and now the project builds (until I re-open Visual Stuido again of coarse) - but hey, at least now I have a hack.

So here is the official hack:

***HACK ALERT - HACK ALERT - HACK ALERT***

Condition:

a) When building test project get you receive the following build error:
C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamTest\Microsoft.TeamTest.targets(14,5): error : API restriction: The assembly 'file:///C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.
b) You also are using one of the new 'Accessor' objects created by Visual Studio.

Hack (aka work-around):
1.  Remove reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework in test project that is getting the error
2.  Close Visual Studio
3.  Re-open Visual Studio and re-add reference that was removed.

Suspected problem:
The accessor object is loading a reference to the unit testing framework for some reason.

*** END HACK ALERT ***

Answer 3

 

I'm getting the same trouble with a test project in VS 2008. It seems to happen when populating the Test View window then doing a build, it's like both of them load the dll into the vs appdomain. Not explored it further though.

 

I find just closing and re-opening studio does the trick, no need to re-add references.

Answer 4

That unfortunately doesn't work for us.  We have a second developer having this problem now.  Anyone else have suggestions?

Answer 5

I just started having the same problem in a unittest project with Visual Studio 2008.

 

I removed the reference from the unit test project, closed Visual Studio, but did not save the change to the unittest project.

 

Re-ran Visual Studio and the entire solution now builds and runs.

 

Answer 6

Hi guys,

 

Sorry that this post has slipped our attention.

 

I don't know the reason this is happening, nor have i experienced it personally.

 

I would like to investigate more if someone would please send me an example of a project you have that is experiencing this constantly? Mail it to gserrato at hotmail dot com

 

thanks

Guillermo Serrato

 

Answer 7

It's too happening to me, it's completely unconstant though, so it's hard to generate a scenario where it happens contantly. However some of you should face this issue soon or later in your labs, so, please, take that chance to debug it.

 

 

Cheers!

Answer 8

It happens to me when I right-clicked on one of the method and choose "Creat Unit Tests.." command. I choose for the new test the old file that was created by wizard a long ago.

 

 

Answer 9

Today I got the API restriction error too.

I solved the problem by doing the following:

 

Shelve the changes, but only the .cs files not the project or solution files.

Now throw away your entire solution folder.(or rename the folder)

Get latest from source control.

Unshelve changes.

 

Worked for me. Hope it helps.

 

Regards,

Freek Bos

The Netherlands.

Answer 10

I have this error too. It keeps returning... very annoying.

When I have enough of it I remove the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll reference from my test project, reload visual studio and then add it again. It's solved then... ....for some time... until it returns... .

 

Update: I had a second project referencing the DLL (I don't know why though, think I auto generated a testclass in that project), I removed it, and now the problem is solved.

Answer 11

Here's another condition that causes it for our team occasionally.

When you closed Visual Studio you had the 'Test View' window focused - this doesn't necessarily mean it was pinned, but it was the top most of the test windows (us for example, will have Test List and Test Results also loaded) when Visual Studio was closed (even if it was minimized).

When you load the solution again and run the tests, you get the error.

We've found that if you make the 'Test List' window your top most of the test windows (pinned or not (minimized/hidden)), close Visual Studio.  Open your solution, then before doing anything else build the entire solution, you'll be okay.   We've only had this technique fail for our team once, and just a repeat of the steps seemed to make it work.

I'd love to see someone from the Test Team say that this is a 'known' bug and it is fixed in the service pack for Visual Studio, or least give all of us some sort of feedback.   I'm sure there are many others who have read our various work-arounds we've posted and just didn' t click 'Mark as Answer'; I'm sure there's more than just a handful of us with the problem.  A bug that gives such a cryptic error message should get some sort of official acknowledgement.

Answer 12

I am pretty sure this is related to the use of private accessors. Even though we stopped using this sh** a long time ago I figured why not try it again after VS2008 + SP1. Who knows, maybe they have gotten it together and it would be more elegant to not have to make the methods under test internal (relying on InternalsVisisbleTo) instead of private as they should be. Me replying in this post should tell the rest of the story. After removing the 'Test References' folder and making the necessary changes, now bypassing the accessor, everything is ok again.

So steps to remove problem:

- Remove private accessor

- [assembly: InternalsVisibleTo(...)] in AssembliInfo.cs of project containing unit under test

- If unit under test declred as private (probably the reason why you went for a private accessor in the first place) make it internal instead

 

Happy coding

Answer 13

I've logged a bug to VS, located here, in case anyone would like to follow it:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=371991

 

Cheers,

Answer 14

I proposed SurfDude's recomendation as an answer. I solved this problem the same way.

I did a search in the solution folder (not project) for "UnitTestFramework" and found a reference to it in a project that it didn't need it. I removed that reference, and everything is fine now.

Maybe it's a sort of circular reference thing? The test project and the project being tested both had a reference to the UnitTestFramework assembly...

We were getting this error on our build server, but not on any of the developer's machines. Go figure.

Answer 15

 If you are going to use private accessors in any framework unit test assembly in your solution, use it in all framework unit test assemblies.  Even if you have to refer to something you don't need to make a private accessor.  Even if you create a "shill target" assembly, you need to have in it in all of them.

Also, we had previously attempted to overcome the inability of Team Build to find the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll by registering it in the GAC.  As always, when you mess with fire you get burnt.  At this point, I  add the following in build scripts (update the path as appropriate to find Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll)

<ItemGroup>
<AdditionalReferencePath Include="c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\" />
</ItemGroup>

Answer 16

I believe this error started to appear on my machine (Vista Enterprise + VS2008 SP1) right after I unchecked the option (Tools -> Options) Test Tools -> Execution -> Performance -> Keep test runner running between test runs.
My reasons to believe so is if you think the project reference points to the PublicAssemblies directory and then if the Test Runner itself loads the assembly from the GAC, we have a problem / two locations.
But if you let the test runner to be running it will start up once (and load the assembly from the GAC) and already be loaded into the AppDomain. If the test runner stops and starts it needs to load the assembly for each run and then it interferes with the project reference (which points to the other location).

Uhm.. this was at least what I could think of. Reading all other posts about this matter makes me think it is quite more complicated.

- Johan

---

Johan Andersson

Answer 17

Follow up on my previous post to this thread. Right after my last post I switched back to the default setting (keeping the test runner running between test runs) and I still got the error, though intermittently.

---

Johan Andersson

Answer 18

Remove Test References folder,do not use accessor ,the problem is solved!

---

系统架构和设计 编程 新技术研究

Answer 19

My Test References folder is empty. I do not use accessors, only InternalsVisibleToAttribute in the assemblies under test.

---

Johan Andersson

Answer 20

Hi

I tried a few things here, such as removing and adding the UnitTestFramework.dll.

Eventually I just went to Exceptions => Managed Debug Exceptions and UNTICKED "Throw". It now works for me.

This doesn't explain why I was getting the error, but does at least allow me to build my solution and actually do some work.

Answer 21

This did indeed work for me. In fact, by toggling the LoadFromContext  Thrown option, I was able to reproduce the error everytime. You may have to customize your debug toolbar to view the Exceptions... item.

1. Try View->Toolbar-> Customize
2. Select Debug from the Categories Commands tab.
3. Then drag the Exceptions... item from the Commands list to your debug toolbar.
4. Click close on the Customize dialog

 

Answer 22

The following worked for me:

- remove references to Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll from the projects
- close Visual Studio
- clean all obj and bin folders
- remove *.suo files
- reopen Visual Studio
- try to compile the project, if there are errors with the unknown namespace then it looks you're on the right track. Just add the references back and compile again.

Hope this helps.

Tadeusz

Answer 23

After removing all UnitTestFramework references from all projects in the solution, Tadeusz's solution worked perfectly for me. Fortunately I only lost one day to this bug.

Thanks

Answer 24

I just wanted to mention selecting 'Test View' tab and closing/restarting VS2008 SP1 worked for me - thanks!

Answer 25

We've found that if you make the 'Test List' window your top most of the test windows (pinned or not (minimized/hidden)), close Visual Studio.  Open your solution, then before doing anything else build the entire solution, you'll be okay.   We've only had this technique fail for our team once, and just a repeat of the steps seemed to make it work.

Thanks for this solution. I've had this problem and so far I've been just rebooting the whole computer which seemed to be only way to resolve it. Above method is faster and works.

Answer 26

The accessor definitely caused my problem.  I didn't need it for testing so I deleted it at things started working.

Answer 27

just close the VS and reload the solution, you will not see the error. Atleast it worked for me.

Answer 28

I am getting same error in vs 2010 premium. I created a build definition and given settings. RUn the build giving me error.

Answer 29

Did you ever figure out the problem? I'm running into it too.

Answer 30

check what the others guys have said (thanks so much)

Look in solutions folder for "ModuleIds.xml" look at the last entry and you will see a duplicate such as:

<Module PersistentId="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" ModuleId="Microsoft.VisualStudio.QualityTools.UnitTestFramework" />

 <Module PersistentId="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" ModuleId="Microsoft.VisualStudio.QualityTools.UnitTestFramework_1" /> 

This was caused in VS2008 by using the unit test Wizard to add additional Tests. Obviously the Wizard does not check to see if "UnitTestFramework" already exists in "ModuleIds.xml"

All fixed in under 2 mins.

Suggest the MS guys add a fix to VSTS2008 and it it happens in VS2010 - shame on them.

 

Doug

 

Answer 31

A simple close and open the VS2010 IDE helped me get rid of this error. 

---

B A

Answer 32

Ultimately the hack works. Just one thing to add - I was getting this error while running ourbuild script in powershell, so obviously a close/reopen of UI was not an option. 

Turns out there were msbuild.exe tasks stuck in process monitor. I killed the tasks, and reran the build scripts and that resolved the pesky error.

Would be nice to hear from VS team as to cause of this error...

Answer 33

Hi,

I was getting this error and the solution in the following post resolved it for me.

http://geekswithblogs.net/jakob/archive/2010/06/08/tfs-2010-build-dealing-with-the-api-restriction-error.aspx

Hamid