Ich bin auf diese Frage gestoßen, als ich nach einer Lösung für ein bestimmtes Problem gesucht habe: MSBuild konnte das Veröffentlichungsziel nicht für eine VS2012-Lösung ausführen, die in VS2010 gestartet wurde, als sie über die Befehlszeile aufgerufen wurde (speziell über TeamCity):
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\2.3\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
MSBuild suchte nach den Azure SDK 2.3-Zielen am VS10-Speicherort (C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Windows Azure Tools \ 2.3 \ Microsoft.WindowsAzure.targets). Die Ursache wird von Sayed Ibrahim Hashimi in einem Blog-Beitrag erklärt und läuft , wie ich es verstanden habe, auf einige Entscheidungen hinaus, die sie getroffen haben, während sie die versionierungsübergreifende Kompatibilität für Lösungsdateien ermöglichen. Die Lösung war einfach: Fügen Sie dem MSBuild-Aufruf die VisualStudioVersion-Eigenschaft hinzu:
msbuild.exe MyAwesomeWeb.sln /p:VisualStudioVersion=11.0
In der Praxis überschreibt dies Folgendes in jeder csproj-Datei:
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
Vermutlich könnten Sie das gleiche Ergebnis erzielen, wenn Sie alle von Hand bearbeiten, um 10.0 durch 11.0 zu ersetzen, aber das könnte die Abwärtskompatibilität beeinträchtigen - ich habe es nicht versucht. Ich habe auch kein Update auf VS2013 versucht, um festzustellen, ob das Problem weiterhin besteht.
Zum Abschluss beantworten Sie die Frage: Ja, es gibt einige Unterschiede, bevor Sie "konvertieren" (unter Verwendung einer der von anderen Antwortenden angebotenen Methoden), und einige Unterschiede bleiben danach bestehen.