Каким образом разработчики VS2008 нацелены на .net 2.0 (но не на пакет обновления), чтобы избежать сбоев во время выполнения?

Question

Итак, я хочу обновить свою команду разработчиков до VS2008. Как предприятие, мы еще не развернули среду выполнения 3.5.

Из некоторого прочтения кажется, что установка VS2008 автоматически даст вам .net 2.0 SP1, который имеет несколько новых API, и когда вы настроитесь на время выполнения 2.0, он примет 2.0 SP1.

Но если SP1 не будет выпущен для наших пользователей, это приведет к перерывам во время выполнения.

1. Есть ли в любом случае целевой VS по сети dotnet 2.0 (НЕ SP1)?
2. Существуют ли другие решения этой проблемы, чтобы разработчики не использовали API-интерфейсы, которые компилируются и работают локально, но не работают в процессе производства?

Я вижу, что у fxcop есть проверка для этого, но должно быть более надежное решение этой проблемы.

Answer 1

Это может быть сложно или просто. Мы прошли оба маршрута:

1. Простой способ: создать сервер сборки, на котором установлена ​​только .Net 2.0. Автоматизируйте сборку для запуска при регистрации (мы используем CruiseControl.Net). Вам придется использовать MSBuild из командной строки для создания проектов.

2. На машинах с установленным 3.5 многие инструменты MSBuild заменяются даже при запуске MSBuild из каталога платформы .Net 2.0. Чтобы избежать этого, вы должны создать приложение, которое заставляет продолжать использовать только среду выполнения .Net 2.0. Это не легко. Мы напрямую загружаем проекты и вызываем сборку с использованием фреймворка Microsoft.Build. *. Одного этого еще недостаточно. Вы должны закрепить сборки, которые вы хотите использовать, в вашем файле .config:

   ... т. д. ...

Кстати, у вас также могут возникнуть проблемы с проектами, недавно созданными в VS2008, ожидающими свойство MSBuildToolsPath, которое необходимо определить. Вы можете определить это в командной строке, если используете MSBuild, или указать это программно, если используете второй параметр:

engine.GlobalProperties.SetProperty( "MSBuildToolsPath", msbuildPath );

Answer 2

Возможно, стоит взглянуть на элемент конфигурации поддерживаемый рабочий день . Но я не уверен, может ли это помочь.