Работа с несколькими версиями Visual Studio

Я пытаюсь найти способ использовать несколько версий Visual Studio в одном и том же наборе проектов. Большинство нашей команды использует 2008 год, но я тестирую 2010 год. Все проекты - С#.

Как я понимаю, Visual Studio 2010 настаивает на обновлении всех проектов, поэтому невозможно оставить все файлы решений/проектов в виде версий 2008 года. Я действительно не хочу разветвлять все исходное дерево, поэтому я хотел бы найти способ совместного использования нескольких версий файлов проекта. В настоящее время я дублировал все файлы .sln и .csproj, поэтому у меня есть:

# 2008 versions
SolutionName.sln
ProjectA.csproj
ProjectB.csproj

# 2010 versions
SolutionName.vs2010.sln
ProjectA.vs2010.csproj
ProjectB.vs2010.csproj

Проблема заключается в том, что несмотря на то, что версии версий 2010 года, имеющие одинаковые имена сборок, как их сопоставления 2008 года, Visual Studio (2010) полагает, что все проекты ProjectName.vs2010. Переименование проекта в VS завершается с сообщением о том, что файл с тем же именем уже существует.

Я не думаю, что включение версии 2010 в подпапку было бы решением, поскольку оно завело бы любые относительные пути в файлах.

Итак:

  • Есть ли способ убедить VS, что имя проекта не должно быть суффиксным .vs2010 (т.е. не то же имя, что и файл)? Или
  • Я подхожу к этому неправильно? Есть ли лучший способ работы с несколькими версиями VS в тех же проектах?

UPDATE

Моя первоначальная претензия была неправильной, что Visual Studio не смогла найти ссылки на проект, потому что она использовала имя файла. Конкретная проблема, с которой я столкнулся, заключалась в том, что в моих файлах сборки ссылки на проект имели форму:

<ProjectReference Include="..\..\path\to\ProjectName.vs2010.csproj">
    <Project>{48354450-2462-449D-8B32-EFECA39F6CD7}</Project>
    <Name>ProjectName</Name>
</ProjectReference>

Файлы проекта, которые я скопировал, по-видимому, имеют другой идентификатор (или что-то еще в элементе <Project>. Простое удаление элемента из файла сборки решило эту конкретную проблему:

<ProjectReference Include="..\..\path\to\ProjectName.vs2010.csproj">
    <Name>ProjectName</Name>
</ProjectReference>

Сказав, что весь процесс дублирования файлов проекта и решений на самом деле был большим, чем это стоит, поэтому я не рекомендую этот подход.

ОТВЕТЫ

Ответ 1

Часто ли вы меняете проекты?

Вы можете просто работать с обновленной версией файлов csproj и sln. Таким образом, вы должны зафиксировать/зарегистрировать все изменения в файлах исходного кода, за исключением файлов проекта, которые в любом случае не изменяются (кроме добавления новых файлов).

Затем, если вы хотите зафиксировать изменения в файлах проекта, вы должны работать с промежуточной локальной версией файла VS2008 и выстраивать его в очередь с помощью ваших любимых инструментов разметки/слияния, прежде чем в конце концов использовать эту версию VS2008. Это будет какая-то локальная ветвь.

Ответ 2

Если вам не придётся работать с разными версиями Visual Studio, те, кто все еще использует 2008, могут обновиться до Visual Studio 2010 Express. Он бесплатный для коммерческого использования, и ему не хватает только нескольких дополнительных функций, которые вам могут не понадобиться.

Ответ 3

Вы пробовали открыть SolutionName.vs2010.sln в простом текстовом редакторе и сменили название проекта?

(form: Project ( "{$ GUID}" ) = "$ DISPLAYNAME", "PROJECTFILE", "{$ OTHERGUID}"

Отвечая на вторую часть вашего вопроса:

Почему важно скрыть, что существует несколько версий файлов проекта? Реальность состоит в том, что есть две версии, и вы должны быть осторожны, чтобы поддерживать их обоих в отношении состояния вашего проекта в любом случае (файлы добавлены/переименованы/удалены, параметры конфигурации изменены).

Наличие двух наборов проектов и файлов решений приведет к различиям между ними, которые сломают вещи.

Как правило: не смешивайте выпуски Visual Studio в том же проекте. Сохранение точной привязки между разработчиками избавит вас от многих проблем.

Ответ 4

visual studio 2010 и файлы проектов проекта (.csproj) совместимы бок о бок, если у вас установлены оба редактора, что означает, что вы можете обновить его, работать над ним в 2010 году, а в 2008 году кто-то другой будет работать без каких-либо проблем, единственное предостережение заключается в том, что вам нужно оставить целевую инфраструктуру как .net 2.0 или 3.5, и чтобы те, кто работает в 2008 году, также должны были установить 2010.

Единственная проблема возникает, если они попытаются открыть файл проекта в 2008 году, и у них не установлен 2010 (потому что, как мне кажется, 2010 добавляет новую цель сборки, о которой стандарт 2008 не знает). Я не думал, что это проблема, но я просто столкнулся с ней на прошлой неделе (в веб-проекте), поэтому в некоторых проектах он существует в некоторых формах.

Если вы перейдете по маршруту переименования, лучший способ - открыть файл sln в блокноте и переименовать ссылки csproj на новые имена вручную (добавив новые переименованные пути к папкам), а затем переименовать любые папки за пределами визуальной студии, затем переименование имени файла в проводнике Windows, а затем переименуйте csproj в проводнике Windows, затем откройте решение в visual studio. ваши привязки scm могут быть заблокированы в этот момент, хотя...