Ich spüre die Verwirrung und habe das Gefühl mich zu rechtfertigen :).

Es gibt das .NET 1.0. Das war vor meiner Zeit. Soweit ich weiß, gibt es aber keine ausgelieferten Applikation damit. Der Version 1.1 kam sehr schnell hinterher.

.NET 1.1 war dann sehr lange das einzige verwendete .NET Framework. Alles war einfach. Wollte jemand ohne Installationsroutine ein .NET Programm laufen lassen, brauchte er die Laufzeitumgebung des Frameworks. Das hat man damals auch so dokumentiert und alles war gut.

Jetzt gibt es .NET 2.0 und hui auch schon .NET 3.0. Wer mutig ist hat sogar schon .NET 3.5 Beta dabei.

Leider wissen das die System Requirements Dokumente von damals nicht mehr. Die schreiben ganz brav noch von einem .NET 1.1 Framework. Nur dummerweise kann es sein, dass Software, die mit dem .NET 1.1 Framework entwickelt wurde auch mit .NET 2.0 läuft. Jetzt wird es zu kompliziert. Jetzt beginnen die Anwender mitzudenken. Und werden verwirrt!

Die Software verlangt nach 1.1, läuft aber auch mit 2.0. Betrug? Absichtliche Verwirrung?

Die sauberste Lösung, wäre per Manifest das gewünschte Framework zu verlangen. Und zwar das, gegen das die Applikation entwickelt und getestet wurde. Dann ist alles wie es der Anwender erwartet und der Entwickler hat ein Freiheitsgrad weniger zu testen.

Natürlich bliebe noch die Methode, einen großen Installer zu bauen, dort das benötigte Framework mit reinzupacken und das alles zu verteilen. Das geht auch immer. Nur hat man dann alle Blogger am Hals, die die Größe der Installationspakete kritisieren. Amüsanter weise wäre man mit den .NET Framework Laufzeitinstallationspaketen ziemlich genau in Größenordnung vom Adobe Acrobat Reader. Und der kriegt seine 20MB ziemlich oft um die Ohren gehauen.

Lustig finde ich dann die Befürchtung, dass Softwareentwickler "[...] Meldungen wohl jeweils manuell programmieren" müssen: Wenn es mal soweit kommt, dass Entwickler selbst programmieren, dann ist aber alles zu spät!

:)

Wenn meine Zeitmaschine endlich fertig ist, werde ich nicht nur gegen vorhandene, sondern auch zukünftige Laufzeitumgebungen testen. Oder noch viel besser, ich werde alle alten Applikation immer auf das neueste Framework portieren. Das wäre toll!

Das bisherige WPF Project wurde jetzt zu Gunsten eines dringenderen ASP.NET Projekts auf Eis gelegt. Schade, WPF hatte gerade angefangen Spaß zu machen. Ein bisschen Warten schadet dabei aber sicher nicht. Vielleicht finden sich beim nächsten Ansatz mehr Antworten als Fragen über Google.

Gegen WPF ist ASP.NET 2.0 eine sehr ausgereifte und weit verbreitete Technologie. Viele Fragestellungen sind gelöst und gut dokumentiert. Dafür haben wir einen sehr jungen Webserver in Vista gekriegt IIS7. Der geht mit ASP.NET nativ sehr viel besser um. Hat man gelesen. Umso überraschter war ich, daß das F5 Debugging mit Visual Studio nicht geht.

Es gibt diverse Lösungen. Die im Moment aber noch in die Kategorie Workaround gehören:

Fix problems with Visual Studio F5 debugging of ASP.NET applications on IIS7 Vista

Die März CTP von Orcas gibt es zum Download. Irgendwie ist die URL auf meinem neuen Vista Heimarbeitsplatz in den IE gewandert und nicht in den FireFox:

Aus dem Screenshot kann man 2 Dinge lernen:

• Ein Download Manager würde die Downloads übersichtlicher anzeigen.
• Mein Internet-Provider hat noch nicht das schnellere DSL aktiviert :).

Was man aus dem Screenshot nicht lernen kann:

• Selbst im Internet Explorer 7 gibt es immer noch keinen Retry bei Downloads. Ein kleiner Schluckauf in der Leitung und alles steht.
• Das von den 10 Download Dialogen in der Früh nur noch 10 Dialoge mit Timeout Error übrig waren.