Насколько велик риск при тестировании сборки .net 3.5 с использованием тестовой сборки .net 4.0

Question

Я понимаю, что Visual Studio 2010 sp1 теперь позволяет тестовым проектам работать с 3.5. Однако по разным причинам, которые я не полностью осознаю, наши тестовые проекты по-прежнему ориентированы на dot net 4.0.

Общий вопрос в заголовке. Насколько велик риск?

В частности, это, вероятно, означает, что тесты будут выполняться в CLR v4, тогда как многие из наших клиентов будут использовать CLR v2. Кроме того, похоже, что в тестах используется v4 библиотечных компонентов (таких как System.Data), хотя приложение построено для v2.

Один метод (System.Data.SqlClient.SqlBulkCopy) содержит ошибку в v2, которая была исправлена ​​в v4. Наше тестирование пропустило это.

Оставляя в стороне CLR, как я могу заставить мое приложение использовать v2 некоторой библиотеки, даже если на нее ссылается (загружается в домен приложения) тестовая сборка v4? Я экспериментировал с примером и, похоже, не смог его реализовать. Мое приложение 3.5 ссылается на System.Data v2 и выводит номер версии сборки на консоль. При вызове из тестовой сборки 3.5, версия 2.0. Из тестовой сборки 4.0, версия 4.0. ("Конкретная версия" установлена ​​в значение true в ссылке из моего приложения)

Answer 1

У меня нет ответа на этот вопрос, поэтому мы решили обойти проблему, вернув наши тестовые проекты в dotnet 3.5.Это означает, что тесты выполняются под CLR 2.0.Однако мы по-прежнему используем MSTest из VS2010 и по-прежнему можем использовать изящные функции 2010 года, такие как категории тестов и тесты на основе данных.

Answer 2

Это должно дать вам то, что вам нужно:

Непрерывное выполнение в процессе