Oder: Wie Automatic Properties für .NET 2.0 kompiliert werden können

In meinem Beitrag über Automatic Properties in .NET 2.0 beschrieb ich, das standardmäßig VS2008 eine Klasse mit Automatic Properties für das .NET Framework 2.0 kompilieren kann, während MSBuild das von Haus aus nicht tut. Dank des Tipps von Tobi denke ich nun die Ursache der Verhaltensunterschiede erkannt zu haben.

Entscheidend für die Verhaltensänderung ist das ToolsVersion-Setting von MSBuild. Es scheint so zu sein, das VS2008 immer die ToolsVersion 3.5 verwendet, unabhängig vom eingestellten Target Framework. D.h. das VS2008 MSBuild mit den Parametern p:/TargetFrameworkVersion=v2.0 /toolsversion=3.5 aufruft.

Im Übrigen wäre dies sogar legitim, denn schließlich steht in der (bei einer durch VS2008 angelegten) .csproj-Datei im <Project> Element das Attribut ToolsVersion="3.5". Zu Schade aber auch, dass VS2008 die Einstellung in der .csproj-Datei zu ignorieren scheint, denn ändert man z.B. manuell den Wert des ToolsVersion-Attributs auf “2.0″, kompiliert VS2008 das Projekt und die Klasse mit den Automatic Properties immer noch einwandfrei.

Anders bei MSBuild. MSBuild achtet auf die csproj-Einstellung genauso wie auch auf das Überschreiben der Einstellung mit Hilfe des /toolsversion-Switches.

Fazit: Die Build-Tools von MSBuild sind wohl dafür verantwortlich, das die für das kompilieren von Syntactic Sugar (wie z.B. Automatic Properties) benötigten Komponenten (System.Core.dll) geladen und verwendet werden können. So ist es möglich, mit Hilfe der Tools von .NET 3.5 einen mit “den neuen Features” angereicherten Code für das .NET Framework 2.0 zu kompilieren.