1

I'm building 2 solutions in a loop in TFS, and in both of them I have the same test DLL (targeted for 2.0 in the 1st solution, and for 3.5 in the second). Everything is fine on the first pass, but in the second, I get this:

API restriction: The assembly 'file:///D:\Builds\1\Project\Main\Binaries\FF3.5\Potato.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.

How can I work around this, can I force the unloading of the DLL? Can I do something about the appdomain?

Thanks,

Jeff
  • 522
  • 7
  • 26

1 Answers1

1

You could try this solution, it just involves changing the expression that finds all the test dlls http://geekswithblogs.net/jakob/archive/2010/06/08/tfs-2010-build-dealing-with-the-api-restriction-error.aspx

Edit:

I investigated this further, it seems that the Test Assembly Filespec (2. Basic -> Automated Tests -> Test Assembly -> Test Assembly Filespec on the default template) is using the FindMatchingFiles activity. So you will have to write a pattern with that that will only match the files you think should be loaded. I couldn't find a guide to using the pattern but stuff like this works:

  1. _PublishedWebsites***test*.dll (Find all the dlls the name of which contains the word test in the folder _PublishedWebsites)
  2. test.dll (Find all the dlls the name of which contains the word test in the base folder)
  3. **test.dll (Find all the dlls the name of which contains the word test in all folders below the base folder)

Where as stuff like this does not:

  1. _PublishedWebsites**\bin*test*.dll
  2. *\bin*test.dll
  3. _PublishedWebsites*test****test*.dll
Eva Lacy
  • 1,257
  • 10
  • 24
  • Thanks Eva, but in my case it's not a web application so the fix does not apply. Plus the issue doesn't seem to occur in TFS 2012 so we're strongly considering an upgrade. – Jeff Feb 05 '13 at 14:09
  • Hmm I'm running TFS 2012 and I get that issue. I think your configuration is *probably* different in the two setups. I suggest you have a look through your binaries folder and see if there are two assemblies with the same name. I only used the _PublishedWebsites as an example, it's just a pattern for finding files, you can use it to include the test assemblies that you are interested in. – Eva Lacy Feb 05 '13 at 15:57
  • The link you provided does not mention a loop, I think in that example that TFS finds the test DLLs twice because they're actually there twice, so adjusting the wildcards works. This is not my case, my first loop iteration passes, the second does not. – Jeff Feb 05 '13 at 19:47
  • In your binaries folder you have two folders both of which contain the relevant assembly right? – Eva Lacy Feb 06 '13 at 10:54
  • Correct, but at the root of Binaries I have FF2.0 and FF3.5, both of which contain roughly the same binaries but targeted at a different .net framework. In the first pass (FF2.0) the test DLL gets loaded, and then I get the error when handling FF3.5 in the second pass. – Jeff Feb 06 '13 at 21:18
  • OK try creating an automated test that uses FF2.0\\*\*\\*test\*.dll as it's spec and another that uses FF3.5\\*\*\\*test\*.dll – Eva Lacy Feb 07 '13 at 09:47
  • I posted a program to this thread that allows you to test your search patterns: http://stackoverflow.com/questions/4524910/use-matchpattern-property-of-findmatchingfiles-workflow-activity/24408935#24408935 – invalidusername Jun 25 '14 at 12:42