Comments on: Automatic Properties in .NET 2.0… aber… http://www.gmbsg.com/automatic-properties-in-net-20-aber/ So einfach wie möglich. Aber nicht einfacher. Thu, 04 Mar 2010 09:09:37 +0100 http://wordpress.org/?v=2.8.6 hourly 1 By: Kevina http://www.gmbsg.com/automatic-properties-in-net-20-aber/comment-page-1/#comment-92 Kevina Wed, 29 Oct 2008 11:54:28 +0000 http://www.gmbsg.com/stories/?p=68#comment-92 Keep up the good work. Keep up the good work.

]]> By: GMBSG - Stories » VS2008, MSBuild und /toolsversion http://www.gmbsg.com/automatic-properties-in-net-20-aber/comment-page-1/#comment-42 GMBSG - Stories » VS2008, MSBuild und /toolsversion Sun, 01 Jun 2008 09:29:40 +0000 http://www.gmbsg.com/stories/?p=68#comment-42 [...] meinem Beitrag über Automatic Properties in .NET 2.0 beschrieb ich, das standardmäßig VS2008 eine Klasse mit Automatic Properties für das .NET [...] [...] meinem Beitrag über Automatic Properties in .NET 2.0 beschrieb ich, das standardmäßig VS2008 eine Klasse mit Automatic Properties für das .NET [...]

]]> By: Tobias Hertkorn http://www.gmbsg.com/automatic-properties-in-net-20-aber/comment-page-1/#comment-41 Tobias Hertkorn Thu, 29 May 2008 22:04:15 +0000 http://www.gmbsg.com/stories/?p=68#comment-41 Hallo, 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 Hallo,

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

]]>