Home Dashboard Directory Help
Search

Unit Tests: Error because VS mixes up the debug and release binaries by omjbe


Status: 

Closed
 as Fixed Help for as Fixed


23
0
Sign in
to vote
Type: Bug
ID: 574115
Opened: 7/9/2010 1:16:31 PM
Access Restriction: Public
2
Workaround(s)
view
16
User(s) can reproduce this bug

Description

When I change the configuration (from Debug to Release) then the Visual Studio Unit Test Framework gets confused about the similar assemblies in Debug and Release folder.

It shows a lot error messages in the Output Window and when I try to run the unit tests I get the error message: The method or operation is not implemented.
Details
Sign in to post a comment.
Posted by Ron Jacobs on 7/29/2011 at 10:23 AM
This also occurs on my project where I have the projects building for two different target frameworks (.NET 4.0.0 and .NET 4.0.1) in the same solution.

I have TestProject.csproj (.NET 4) output to bin\release and TestProject.PU1.csproj (.NET 4.0.1) output to bin\release.pu1. The projects both produce assemblies with the same name. This seems to confuse MSTEST.
Posted by jonathanmkc on 7/19/2011 at 10:36 PM
Further digging showed a possible cause for why the workaround I posted worked in my case. In my solution I have two load tests which I normally *disable* using the test list editor. Disabling them there is the only way, as far as I'm aware, to prevent them from running alongside the normal unit tests (since they can't be disabled by adding the "[Ignore]" attribute as can unit tests). Since the VSMDI file which contains this information was somehow disassociated from my solution file, Visual Studio was apparently trying to run these tests as part of the normal test run. I noticed the test count drop by two when I restored the VSMDI file, and the problem was fixed. My assumption is that these were the two load tests being skipped.
Posted by ulf.jzl on 6/10/2011 at 1:13 AM
I run VS 2010 Ultimate SP1 with TFS 2010 and I also have this problem. The workaround doesn't work for me. I need to change configuration (from Release to Debug) save the project and restart Visual Studio, then I rebuild the soultion and it works fine. Is there any hotfix for this problem?
Posted by Pellet21 on 4/6/2011 at 2:23 PM
I got this error when switching Unit Test Project mode from 'Any CPU' to 'x86'. Did the Workaround described in this posting but still got a compile problem building the new Unit Test project with 'Rebuild Solution'. Right-clicked the new Unit Test project and 'Rebuild' and project compiled. Then did 'Rebuild Solution' again and problem is fixed.
Posted by gord888 on 11/8/2010 at 1:18 PM
here's my error message (but the work around i posted seems to work for now)

Error loading <my dll>.dll: The test 'mytest' from '<release\my dll>.dll' that is loading has the same TestId {bbbbbbbb-bbbb-bbbb-bbbb-ebbbbbbbbbbb} as the test 'mytest' already loaded from '<debug\my dll>.dll'.
Posted by Ilya Margolin on 10/19/2010 at 1:43 AM
Is there any workaround?

Also my TFS build runs in debug and fails in release (it's trying to build both) is that related to the bug?
If yes, is there any workaround for that?
Posted by 陳正展 先生 on 8/1/2010 at 6:50 PM
已經修改過來
Posted by Microsoft on 7/27/2010 at 3:25 AM
Thanks for the feedback. The issue is fixed and would available in the next release
Posted by Microsoft on 7/9/2010 at 5:05 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by jonathanmkc on 7/19/2011 at 10:10 PM
I also had some trouble with the error "method or operation not implemented" when running unit tests in Visual Studio 2010. My solution has about 350 tests targeting WCF services and a WPF PRISM/MVVM application. Some tests would still run OK, but when running all tests I would get the error. It started when I used another computer (other than my normal dev workstation) to commit some changes to the solution. At first I thought it might be a platform issue, as the other computer was 32-bit and my normal workstation was 64-bit (both Windows 7 Ultimate). Another thing I noticed was that all my test lists were gone--the VSMDI file (which contains all the test lists) had been removed when I checked in changes from the other computer.

I didn't think this missing file would be related to the problem. However, that missing file was the key. The workaround for my case was to click the "Load Metadata File" button in the test list editor and choose the original VSMDI file. After doing this all the tests run.
Posted by gord888 on 11/8/2010 at 1:16 PM
1) clean solutions in both modes
2) rebuild in the mode you want