Mit der Beta 2 von ASP.Net MVC 2 sind einige nette Features dazugekommen. Areas können nun zum Beispiel innerhalb eines Projektes verwendet werden und die deklarative Validierung erzeugt auf Wunsch neben server-seitigem Validierungscode entsprechende JavaScript-Gegenstücke. Auch die Art, in der Validierungsregeln festgelegt werden, kann nun beeinflusst werden. Somit kann meiner Forderung bezüglich der Notwendigkeit, Validierungsregeln nicht nur auf Entity- sondern auch auf Formularebene zu definieren, nachgekommen werden -- zumindest, wenn man sich die Mühe macht, eine Implementierung für die dazu vorgesehenen Einsprungspunkte zu implementieren. Wünschenswert wäre es, diese Möglichkeit out-of-the-box zu haben.

In der aktuellen Ausgabe des dotnet-magazins berichte ich über diese Neuerungen anhand einiger Beispiele, welche von der Website des Magazins heruntergeladen werden können.




[ Kommentar hinzufügen ] ( 81 views )   |   ( 2.8 / 122 )

---

Dass C# 4 Unterstützung für dynamische Objekte bringen wird, dürfte dem einen oder anderen bereits bekannt sein. Damit soll das Zusammenspiel mit dynamischen Sprachen und COM sowie das Abbilden von dynamischen Domänen erleichtert werden.

Daneben wird jedoch auch die Möglichkeit geboten, eigene Klassen zu entwickeln, welche dynamische Member haben und somit erst zur Laufzeit aufgelöst werden. Das nachfolgend dargestellte Beispiel demonstriert dies, indem eine Instanz von Something erzeugt wird und dieser Werte für zwei bis dato nicht definierte (!) Eigenschaften zugewiesen werden. Danach werden diese wieder ausgelesen und auf der Konsole ausgegeben.

Anschließend werden mit einer Methode RegisterMethod zwei Delegates als Methoden definiert. Die Namen dieser neuen Methoden werden als String übergeben. Danach werden beiden Methode, wie herrkömmliche Methoden, aufgerufen. Im Anschluss daran, wird auch noch das Objekt als Methode behandelt und ausgeführt.

dynamic dontknow = new Something();

dontknow.X = 10;
dontknow.Y = 20;

Console.WriteLine(dontknow.X);
Console.WriteLine(dontknow.Y);

Func<int,int,int> add = (x,y) => x + y;
Func<int, int, int> sub = (x, y) => x - y;

dontknow.RegisterMethod("Add", add);
dontknow.RegisterMethod("Sub", sub);

Console.WriteLine(dontknow.Add(1,2));
Console.WriteLine(dontknow.Sub(1, 2));
Console.WriteLine(dontknow(1, 2));

Mehr ...

[ Kommentar hinzufügen ] ( 97 views )   |   ( 3 / 195 )

---

Für .Net-Projekte stehen unter anderem Plugins für MSBuild und MSTest zur Verfügung. Beide können direkt über die Web-Oberfläche von Hudson installiert werden. Ersteres wird verwendet, um eine Solution zu builden. Zusätzlich habe ich im Zuge des Builds MSTest auf der Kommandozeile angestoßen, um das in dieser Solution enthaltene Testprojekt auszuführen. Mit dem MSTest-Plugin wird anschließend das Ergebnis von MSTest in das JUnit-Format übergeführt, sodass es von Hudson berücksichtigt werden kann. Eine mögliche Job-Konfiguration mit diesen beiden Plugins findet sich nachfolgend.


Mehr ...

[ Kommentar hinzufügen ] ( 293 views )   |   ( 3 / 193 )

---

Über Plugins bietet der beliebte Integrations-Server Hudson Unterstützung für .Net-Projekte. Hierzu finden u. a. Plugins für MSBuild sowie MSTest Anwendung. Ersteres ermöglicht das Erstellen von Visual Studio-Solutions bzw. -Projekten. Anschließend können über einen Kommandozeilenaufruf die so erzeugten Kompilate mittels MSTest getestet werden. Das Ergebnis solch eines Aufrufes ist eine XML-Datei mit der Endung trx, welche sich an einem von Microsoft definierten Aufbau orientiert. Da Hudson die Ergebnisse von Tests allerdings in Form von JUnit-XML-Berichten erwartet, ist diese Datei zu transformieren. Dies übernimmt das Plugin für MSTest.

Da mit .Net 4/ Visual Studio 2010 allerdings der von trx-Dateien verwendete Namespace geändert wurde, funktioniert dieses Plugin nicht mehr. Um diesen Umstand zu kompensieren, ist die xsl-Datei, welche das Plugin verwendet, anzupassen. Diese befindet sich, wenn Hudson direkt über die Kommandozeile gestartet wird, unter C:\Users\BENUTZER\.hudson\plugins\mstest\WEB-INF\classes\hudson\plugins\mstest und nennt sich mstest-to-junit.xsl. In dieser Datei ist lediglich der Namespace [...]TeamTest/20xx auf [...]TeamTest/2010 zu ändern. Danach klappt's mit .Net 4/ Visual Studio 2010...



[ Kommentar hinzufügen ] ( 78 views )   |   ( 3 / 200 )

---

Im Vorfeld der kommenden BASTA! werden einige Speaker zu allgemeinen sowie BASTA!-spezifischen Aspekten der Software Entwicklung befragt. Mein Interview findet sich hier .





[ Kommentar hinzufügen ] ( 66 views )   |   ( 3 / 189 )

---

<<Erster <Zurück | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | Weiter> Letzter>>