Unit Test projects are automatically upgraded to .Net 4.0 target framework - by vs2015junkie

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 483891 Comments
Status Closed Workarounds
Type Bug Repros 11
Opened 8/19/2009 12:00:17 PM
Access Restriction Public


When upgrading a Visual Studio 2008 Unit Test project to Visual Studio 2010, the Target Framework version automatically changes to v. 4.0 even when the original Target Framework version on the Visual Studio 2008 project was v. 3.5.
Sign in to post a comment.
Posted by vs2015junkie on 12/20/2010 at 11:49 AM
Based on this latest blog post, with the release of Visual Studio 2010 SP1, you will now be able to configure Unit Tests to run on at least the .Net 3.5 framework rather than being forced onto .Net 4.0 for Unit Tests:

Posted by kid_kaneda on 11/8/2010 at 5:34 AM
We now have code which runs quite happily in MSTest yet throws exceptions when run in the application - due to covariant casts which are allowed in .NET 4 but not 3.5. Having code that passes unit tests but fails in production like this pretty much defeats the point of unit testing. The fact that the tests are running on a different version of the framework completely undermines their integrity. We can't be sure that code that passes in 4.0 unit tests won't actually fail when run on 3.5.

In all seriousness, how on earth can Microsoft think this is an acceptable solution? If you think that you can run unit tests on a completely different version of the framework and consider results are in any way valid you clearly don't understand some of the basic principles of testing.

I used to be a somewhat of a fan of MSTest, however it is becoming clear that Microsoft are only playing at having a professional quality unit testing solution. They don't seem to understand the implications of their decisions or appreciate the investment that goes into developing a suite of tests.

My advice to clients and to anyone reading this is to stay well away from MSTest, and look to something like xUnit or NUnit. Speaking as a long time MSTest user: folks it's time to move on...
Posted by Bill44077 on 5/22/2010 at 10:03 AM
So - now that VS2010 has gone RTM this issue has not been resolved? We recently bought 48 licenses and our .net 3.5 application with MS tests cannont be build in 3.5? Isn't this supposed to be Multi-Target? So much for simple Continuous Integration?
Posted by GergelyOrosz on 2/2/2010 at 1:32 AM
This move makes the work of teams using both VS2008 and VS2010 and MSTest impossible as VS2008 does not run .NET 4.0 unit test projects. I would not have thought this is the move that is forcing the team to move to NUnit!
Posted by Perica Zivkovic on 11/26/2009 at 4:56 AM
Yes this means that you can use ONLY 4.0 for your unit tests in VS 2010. I see big list of MS customers switching to NUnit because of this...

Really really bad move ...

All please vote for importance of this issue...
Posted by David Beaumier on 11/25/2009 at 10:51 AM
Can someone from Microsoft answer Iain question? I have the same issue.
Posted by Iain Galloway on 11/5/2009 at 1:48 AM

Does this mean it's going to be impossible to create unit test projects in VS2010 for assemblies targetting the 2.0 CLR? (ASP.NET MVC on top of .NET 3.5 SP1 in my case).

My existing unit test projects don't even build due to the dependancy on System.Web which isn't available in a project targetting 4.0.
Posted by Microsoft on 8/21/2009 at 11:51 AM

Correct, we will always convert to the .NET 4.0 Framework for Unit Test for Dev10. Various upgrade fixes have been resolved in future releases. The one exception is VB 3.5 projects due to a few limitations we are working around.

Visual Studio Product Team
Posted by Microsoft on 8/21/2009 at 12:23 AM
Thanks for your feedback. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team