Насколько велик риск при тестировании сборки.net 3.5 с использованием тестовой сборки.net 4.0
Я понимаю, что 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 в ссылке из моего приложения)
2 ответа
У меня нет ответа на этот вопрос, поэтому мы решили обойти проблему, вернув наши тестовые проекты в dotnet 3.5. Это означает, что тесты выполняются под CLR 2.0. Тем не менее, мы по-прежнему используем MSTest из VS2010 и все еще можем использовать изящные функции 2010 года, такие как категории тестов и тесты на основе данных.
Это должно дать вам то, что вам нужно: