Mittlerweile kennen ja einige schon die neuen Features von .NET 3.5 / C# 3.0. Einer der hilfreichen neuen Features sind die Automatic Properties. Mit ihnen lassen sich schnell einfache “nur” get-set Properties implementieren:
public class Parameters
{
public string Option { get; set; }
public int Code { get; set; }
}
Das interessante an den Automatic Properties ist, das sie durch die Art ihrer Implementierung als “Syntactic Sugar” oder “Compiler Trick” mit dem .NET Framework 2.0 lauffähig sind. Das geht sogar soweit, das man mit Visual Studio 2008 Automatic Properties für .NET 2.0-Projekte verwenden kann.
Doch uneingeschränkt einsetzen kann man das Automatic Property Feature nicht – denn, kompiliert man den gleichen Code nur mit MSBuild 3.5 mit Target .NET 2.0 (z.B. mit NAnt am Buildserver), wird der Build mit einem Compiler-Error fehlschlagen:
[msbuild] Project\Parameters.cs(65,7): error CS0501: 'Project.Parameters.get' must declare a body because it is not marked abstract or extern [msbuild] Project\Parameters.cs(66,4): error CS0501: ''Project.Parameters.set' must declare a body because it is not marked abstract or extern
Nun, das liegt wohl wiederum ein wenig an der Art der Implementierung der Automatic Properties als auch an Visual Studio 2008. Denn eigentlich hat MSBuild vollkommen recht, die Automatic Properties nicht zu übersetzen, denn für einige neue C#3.0 Features ist das ExtensionAttribute (System.Runtime.CompilerServices) von System.Core.dll notwendig (.NET 3.5) – so auch für Automatic Properties.
Trotzdem schafft es VS2008, die Automatic Properties für .NET 2.0 zu kompilieren. Ich kenne die Interna von VS2008 nicht, ich nehme aber mal an das wird wohl daran liegen, das VS2008 die System.Core.dll während des Builds aufruft und refenzieren lässt, obwohl der Target der Assembly auf .NET 2.0 steht.
byKevinaonOctober 29th 2008Keep up the good work.
byGMBSG – Stories » VS2008, MSBuild und /toolsversiononJune 1st 2008[...] meinem Beitrag über Automatic Properties in .NET 2.0 beschrieb ich, das standardmäßig VS2008 eine Klasse mit Automatic Properties für das .NET [...]
byTobias HertkornonMay 29th 2008Hallo,
hmm, finde ich sehr interessant ihre beobachtung. leider konnte ich sie so nicht nachstellen – sind sie sicher, dass sie die csc.exe von v3.5 verwenden und ihnen kein falsch gesetzter pfad einen streich spielt? denn eigentlich hat die automatic property meines wissens nichts mit visual studio zu tun – wie sie richtig sagen ist es syntactic sugar, der ein hidden private field automatisch anlegt (siehe z.B. reflector).
denn ihren fehler kann ich nur nachstellen, wenn ich z.B. folgende kommandozeile verwende: c:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe ConsoleApplication1.csproj /p:Configuration=Debug;TargetFrameworkVersion=v2.0 /v:d /toolsversion:2.0 /filelogger /t:rebuild
(statt wie gewohnt /toolsversion wegzulassen oder auf 3.5 zu setzen)
dann erscheint allerdings im entstandenen msbuild.log auch in der dritten Zeile:
Building with tools version “2.0″.
statt:
Building with tools version “3.5″.
und nur dann tritt ihr beschriebener fehler auf.
Könnten sie einmal ein /v:d /filelogger zu ihrer kommandozeile in nant hinzufügen? vielleicht entdecken sie ja, dass sie die falsche tools version verwenden. Und damit die csc.exe aus C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 statt aus C:\WINDOWS\Microsoft.NET\Framework\v3.5 verwenden? Diese könnte dann wie erwartet auch nicht den neuen syntactical sugar auswerten…
Viele Grüße,
Tobi