- Posted by robert on Oktober 31, 2009
Mit Legacy Projekt ist ein Projekt gemeint, das keine automatisierten Tests besitzt und nicht trivial ist. Es scheint unmöglich DI in einem Entwicklungsschritt einzuführen. Es scheint nicht sinnvoll im ersten Schritt die Anwendungsschicht von der Abhängigkeit auf das Container Framework zu befreien.
Meine aktuelle Strategie:
- In kleinen Schritten vorgehen
- Viele kleine Service-Locator einsetzten
- Die Service-Locator arbeiten alle mit der gleichen Singelton Instanz des Containers
- Im Muster denken: "Refaktorisierung in Richtung" wobei die endgültige Refaktorisierung auch Wochen/Monate auf sich warten kann.
- Posted by robert on Oktober 31, 2009
- C#: typeof(someType) gibt den System.Type zurück
- VB.NET: TypeOf someType IS Integer gibt ein Boolean zurück
Das Equivalent zu typeof() in VB.NET ist:
Es hat ein wenig gedauert bis ich verstanden habe das die Beispiele auf der Autofac VB.NET Dokumentationsseite nicht korrekt sind…
Dim builder As Autofac.ContainerBuilder = New Autofac.ContainerBuilder()
builder.Register(TypeOf(Car)).As(TypeOf(IVehicle))
Dim container As Autofac.Container = builder.Build()
… kann natürlich nicht funktieren!
Es muß sein:
Dim builder As Autofac.ContainerBuilder = New Autofac.ContainerBuilder()
builder.Register(GetType(Car)).As(GetType(IVehicle))
Dim container As Autofac.Container = builder.Build()
- Posted by Oliver on Oktober 30, 2009
Die folgende Fehlermeldung erhielt ich heute von unserem IIS7, als ich Camping.Info starten wollte:
Server Error in '/' Application.
Could not load file or assembly 'Microsoft.Cci' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: Could not load file or assembly 'Microsoft.Cci' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Also das Orakel gefragt und u.a. das hier gefunden: http://forums.asp.net/t/1358032.aspx
Standardmäßig unterstützt ein 64-bittiger IIS 7 keine 32-bit-Module (u.a. DLLs). Man kann es ihm aber einfach beibringen :-)
Im IIS-Manager den gewünschten ApplicationPool auswählen und in den Advanced Settings die folgende Einstellung vornehmen:
Der Vollständigkeit halber hier noch ein Link zur Anleitung für den IIS6 auf Windows 2003 Server: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/405f5bb5-87a3-43d2-8138-54b75db73aa1.mspx?mfr=true
Happy Coding!
Oliver
- Posted by robert on Oktober 21, 2009
“LC.exe wurde mit Code -1 beendet” lacht mich in VS2008 als Fehlermeldung an. Schlimm genug das Die Meldung in Deutsch ist, es sind auch keine weiteren Informationen enthalten. Doppelklick führt zu “Microsoft.Common.targets” dem riesigen .NET default MSBUILD File.
Alle gefundenen Probleme verweisen auf kommerzielle Komponenten. Logisch, denn “LC.exe” steht für Licence Compiler. Der Licence Compiler liest eine Textdatei in der Namespace und Assemblynamen aufgeführt werden und erzeugt .licence Files. Bei Gelegenheit hoffe ich noch tiefer in das Thema einsteigen zu können :-)
Lösung des Problems: Alle *.licx Files aus der Solution entfernen. Die Ursache scheinen Inkonsistenzen durch das Versionskontrollsystem gewesen zu sein.
Zwischenstand: Die Anwendung läst sich nun bauen und starten. Auf die schnelle sind keine Nebeneffekte auszumachen.
- Posted by Oliver on Oktober 16, 2009
In unserer Test-basierten Entwicklung hat sich die Verwendung von Setup-Klassen für unsere Entities etabliert. Unsere Tests sehen folgendem sehr ähnlich:
[Test]
public void FetchJoinTest()
{
var cat = _categorySetup.GetPersisted();
var pitch = _pitchSetup.GetPersisted(p => { p.Categories.Add(cat); return p; });
var reserv1 = _reservationSetup.GetPersisted(r =>
{
r.Pitch = pitch;
r.DateFrom = new DateTime(2009, 10, 31);
r.DateTo = new DateTime(2009, 11, 13);
return r;
});
pitch = _pitchService.GetById(pitch.Id);
Assert.That(pitch.Reservations.Count, EqualTo(2));
}
Leider funktioniert der Test so nicht - er schmeißt eine AssertionException, da pitch.Reservations keine Elemente enthält.
Warum nicht???
Nach langem hin und her, bin ich mir endlich sicher, es verstanden zu haben: es liegt an NHibernate's Entity-Cache! Da das Pitch-Objekt ja zum Zeitpunkt der Abfrage
pitch = _pitchService.GetById(pitch.Id);
noch in der aktuellen Session geladen ist (was NHibernate meines Wissens nach anhand der ID feststellt), wird kein neues Objekt vom Typ Pitch instanziiert, sondern das schon existierende, pitch, zurückgegeben. Dieses enthielt aber noch keine Reservierungen zum Zeitpunkt der Persistierung - und so, wie es aussieht, werden diese auch nicht nachträglich geladen (für ein Objekt, das schon in der Session lebt).
Die Lösung ist jetzt gar nicht mehr so schwer: wir schmeißen das vorhandene Objekt einfach weg! Dafür gibt es Session.Evict():
[Test]
public void FetchJoinTest()
{
var cat = _categorySetup.GetPersisted();
var pitch = _pitchSetup.GetPersisted(p => { p.Categories.Add(cat); return p; });
var reserv1 = _reservationSetup.GetPersisted(r =>
{
r.Pitch = pitch;
r.DateFrom = new DateTime(2009, 10, 31);
r.DateTo = new DateTime(2009, 11, 13);
return r;
});
_nHibernateHelper.Session.Flush();
_nHibernateHelper.Session.Evict(pitch);
pitch = _pitchService.GetById(pitch.Id);
Assert.That(pitch.Reservations.Count, EqualTo(2));
}
Jetzt läuft der Test mit Erfolg durch. Happy Coding!