.net 3.5 unit tests no longer work

[FruitcakeElemental]

Steps to reproduce

Create a project targeting .net 3.5 in the latest version of visual studio (15.9.5)
Create a unit test
Run the unit test

Expected behavior

Tests will run successfully

Actual behavior

Tests fail with the following message:
Microsoft.VisualStudio.TestPlatform.ObjectModel.TestPlatformException: Framework35 is not supported. For projects targeting .Net Framework 3.5, please use Framework40 to run tests in CLR 4.0 "compatibility mode".

Environment

Windows 10 x64
Visual Studio 15.9.5

From investigating both the cause and what the error message was indicating for me to do I found this. Suggesting that the change may have been intentional, however the suggested solution of changing the targeted .net framework to 4.0 is completely unacceptable.

There are so many projects dependent on targeting .net 3.5 due to legacies that they deal with. In my case Unity3d is the main restriction upon this project and whilst unity3d has upgraded to 4.6.1 recently, there are still numerous bugs in the mono environment on mac/ios and we can't just switch to it. Just telling developers to change the targeted platform is both ignorant of legacy systems and extremely arrogant.

Further complicating the issue is nuget, it will pull and update projects based upon your targeted framework, so if you change the targeted framework you won't get the same nuget package. If i split a project up into a 3.5 source project and 4.0 unit test project, how can I be sure I'll have the same packages and that running under 4.0 the behavior will be the same as a live environment.

Any other suggestions that don't involve me targeting 4.0?

[mayankbansal018]

@PBoraMSFT , @cltshivash This limitation has been called out in initial RFC's of test platform,

Can you please take a call on what should we do for such scenarios?

[FruitcakeElemental]

Can I get some assistance in working around this problem? It's halted my development of this 3.5 work, and its not a simple task to drop back versions of visual studio (I don't even know what version that I can drop back to that will support 3.5).

I also need to point out that there was 0 warning that this would happen, no notices, I can't even find information in release notes on this change. By that definition I would dispute the 'by design' tags of this issue. There also doesn't seem to be any plan for migrating or supporting 3.5 code bases, or even just letting people run old versions of vstest.

[mayankbansal018]

@FruitcakeElemental apologies for delay on this. @singhsarab , can you please prioritize this

[mayankbansal018]

The fix will be available in next release of test platform, @FruitcakeElemental is it okay if we close this issue for now?

[FruitcakeElemental]

Ok, whats the ETA on the next release?

[mayankbansal018]

We expect next release around 17-18th Feb

[jhedlund]

Will this be released in a Visual Studio 2017 update or only for 2019?

[singhsarab]

@jhedlund This will be available in VS 2019.
If servicing for VS 2017 allows, we will try to take it for that release as well

[jbrown16]

@singhsarab I've also run into the exact same issue that @FruitcakeElemental did, except I'm using VS 15.9.7. This would be a highly desired fix for my line of work seeing as I can't support 4.0+ for the foreseeable future. Please continue this test support for VS 2017 if at all possible.

[jhedlund]

Agree with @jbrown16 . It was working fine in an earlier v15.9.x release...

[jbrown16]

@singhsarab @mayankbansal018 The next update for VS 2017 came available for me (15.9.8) and I updated but I still get this error when running my unit tests: Microsoft.VisualStudio.TestPlatform.ObjectModel.TestPlatformException: Framework35 is not supported. For projects targeting .Net Framework 3.5, please use Framework40 to run tests in CLR 4.0 "compatibility mode". Apparently this still isn't fixed. Is there any way that this fix could get pushed to the 2017 version as well?

[singhsarab]

@jbrown16 I am trying to push it for 15.9.9, will update once it is in. Thanks for your patience.

[jbrown16]

This issue has been resolved in VS 2017 v15.9.10 (#1945). @FruitcakeElemental @jhedlund