Wenn man weiß, wie es geht, ist alles einfach. Aber JavaScript in UserControls innerhalb eines UpdatePanels funktionstüchtig zu bekommen hatte für mich - bis heute! - immer etwas mit Magie zu tun... Hinzu kam heute, dass ich noch Sys.UI.DomElement-Methoden nutzen wollte (aus der AJAX-Bibliothek). Folgende Versuche habe ich gemacht: 1. Page.ClientScript.RegisterClientScriptBlock(GetType(), "helpful_css_" + ClientID, script, true);2. ScriptManager.RegisterClientScriptBlock(this, GetType(), "helpful_" + ClientID, script, true);3. Page.ClientScript.RegisterStartupScript(GetType(), "helpful_css_" + ClientID, script, true);4. ScriptManager.RegisterStartupScript(this, GetType(), "helpful_css_" + ClientID, script, true); // <-- this is it!   Zu 1. und 3. ist zu sagen, dass sie innerhalb einen UpdatePanels nur nach dem ursprünglichen PageLoad funktionieren, nicht nach einem asynchronen Postback. Also fallen sie raus. Außerdem fallen 1. und 2. weg, weil an der Stelle, an der der hier übergebene JavaScript-Code in die Seite generiert wird, der $Sys-Namespace noch nicht definiert ist (ähnlich wie hier: http://encosia.com/2007/08/16/updated-your-webconfig-but-sys-is-still-undefined/). Bleibt nur 4. Und 4. funktioniert sowohl nach dem initialen PageLoad als auch nach einem async Postback und man kann $Sys verwenden. Wunderbar! 1. oder 2. bleiben allerdings nützlich, wenn man Custom Javascript in die Seite einfügen will, um es weiter unten auf der Seite zu nutzen. Wahlweise kann man natürlich auch die Methode RegisterClientScriptInclude nutzen, um das Javascript in eine eigene Datei auszulagern. Soviel dazu. Oliver

Bevor ich noch x Mal durchs Web klicke, hier der Einzeiler: .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: Consolas, "Courier New", Courier, Monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } hplCatBox.Attributes["onclick"] = "javascript:$find('" + cpeInqCat.BehaviorID + "').expandPanel(new Sys.EventArgs)";

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

In unserem Projekt verwenden wir einen Cache zum Vorhalten von oft benutzten Daten, u.a. für Länder und Bundesländer. Für die Übersetzungen derselben in viele Sprachen habe ich einfach je eine einfache Tabelle angelegt mit einer Referenz auf das jeweilige (Bundes-)Land, dem Sprachen-Isocode und dem Namen in der entsprechenden Sprache. Per NHibernate-Mapping dann die Übersetzungen als <bag> an das (Bundes-)Land angeheftet - fertig. Beim NUnit-Testen bekam ich nach dem Einbau der Übersetzungen beim Update von (Bundes-)Ländern allerdings diesen Fehler: NHibernate.HibernateException: Illegal attempt to associate a collection with two open sessions. Offensichtlich waren die neuen Collections an den Domainobjekten Schuld. Was war passiert? Beim Aufrufen der Frontend-Seiten kam dieser Fehler nicht... Nun, die Exception gibt uns einen guten Tipp: Wir haben zwei offene Session, mit denen die Collection von Übersetzungen assoziiert werden soll. Aber warum nur in den Tests und warum dort überhaupt? Eine erste Erklärung: Im Frontend benutzen wir für die NHibernate-Sessions das One-Session-Per-Request-Pattern, so dass alle Manipulationen an den Session-Objekten (inkl. Update) innerhalb derselben Session passieren. Außerdem funktionierte dort das Dispose der Session zuverlässig. In unseren Tests war das ja leider nicht der Fall, so dass wir also irgendwie eine geöffnete Session nicht schließen. Durch die Benutzung eines Caches kamen wir in die Verlegenheit, Länderobjekte in einem Testcase in den Cache zu schreiben und diese in einem folgenden Testcase wiederzuverwenden. Als an dieser zweiten Stelle ein Update passieren sollte, knallte es, denn das Objekt im Cache hielt eine Referenz auf NHibernate-Collection, die noch mit einer vergangenen Session assoziiert war. Beim Update versucht NHibernate aber, dieselbe Collection an die aktuelle Session zu binden, was eine Exception wirft. Der Cache war also Schuld. Oder zumindest war das mein erster Gedanke. Und tatsächlich: Wenn ich im [SetUp] der NUnit-TestFixture ein Cache.Clear() aufrufe, verschwindet der Fehler! Keine Überraschung, denn jetzt benutzen wir ja keine Objekte aus "alten" Sessions mehr. Aber Moment mal, im Frontend benutzen wir doch denselben Cache?! Und da gibt es diesen Fehler nicht. Nach ein wenig Haareraufen, kam ich dann zurück zu der Feststellung, dass es ja ein Problem mit einer offenen Session gab. Also setzte ich da nochmal an. Für das Lifecycle-Management unserer Serviceklassen benutzen einen Autofac-IoC-Container. Dieser stellt auch die NHibernat-Session bereit. Zum Benutzen der Services haben wir eine ServiceLocator-Klasse, die uns die vom Container generierten Serviceinstanzen auf Anfrage zurückgibt. Um diese Architektur in den NUnit-Tests zu nutzen, schrieben wir flugs eine Basisklasse BaseTest, von der alle Testklassen ableiten und fortan Zugriff auf alle Services haben. Das Lifecycle-Management des Containers wird dort ebenfalls verwaltet.         public BaseTest()         {             InitializeContainer();         }         ~BaseTest()         {             DisposeContainer();         } Wie sich nun herausstellt, eine dumme Idee! Beim Debuggen stellte ich fest, dass der Konstruktor zwar von jeder TestFixture (also jeder Testklasse, die selbst mehrere Tests enthält) in Reihenfolge aufgerufen wird, dass aber der Destruktor einer Testklasse keineswegs zuverlässig vor dem Konstruktor der nächsten Testklasse ausgeführt wird! Damit wird der Container der ersten Testklasse nicht Dispose'd und in Folge die NHibernate-Session nicht geschlossen, so dass wir den o.g. Fehler bekommen. Wahrscheinlich ist das Ausführen von Businesslogik in einem NUnit-TestFixture-Konstruktor bzw. viel schlimmer im Destruktor ein absolutes NoNo. Dafür gibt es schließlich die Attribute [TestFixtureSetUp] und [TestFixtureTearDown]. Mit dem folgenden Code funktioniert denn auch alles wie gewollt:         [TestFixtureSetUp]         public virtual void TestFixtureSetUp()         {             InitializeContainer();         }         [TestFixtureTearDown]         public virtual void TestFixtureTearDown()         {             DisposeContainer();         } Ein kleiner Wehrmutstropfen bei dieser Lösung ist, dass man beim Testklassen-Schreiben jetzt daran denken muss, diese Methoden zu überschreiben, wenn man weitere Funktionalität in [TestFixtureSetUp] und/oder [TestFixtureTearDown] benötigt... Alles Gute, Oliver

Nach zwei unabhängigen Fällen sieht es nun deutlicher danach aus, dass o.g. Kombination Probleme aufwirft und zwar mit dem EventHandling auf Serverseite. Genauer: Es werden keine Events für DropDownListen, LinkButtons u.ä. gefeuert, obwohl sie sollten. Das macht die Funktionalität im TranslationPanel kaputt.   Spannend ist folgendes Phänomen: Auf einer Seite mit der genannten Kombination und geöffnetem TranslationPanel geschieht folgendes: Erstes Mal die DDL benutzen -> nicht (optisch; im Fiddler sieht man aber einen Request) Zweites Mal die DDL benutzen -> die Seite wird neu geladen (komplett!) Drittes Mal die DDL benutzen -> funktioniert so, wie es soll Ab jetzt funzt es so wie es soll. Warum? Das also als Notiz an mich selbst. Mal schauen, was draus wird. Oli

Scott Guthrie kündigt den offiziellen Support von jQuery in seinem Blog an. jQuery wird offiziell ausgeliefter Teil von ASP.NET jQuery wird von Visual Studio unterstützt, mit erweiterter/annotierte Intellisense.  Mircosoft wird jQuery offiziell supporten Komponenten von ASP.NET AJAX sollen auf jQuery Syntax basieren. Die MIT (open source) Lizenz von jQuery wird dabei übernommen. Ein großartiger Schritt :-) der mich wieder eine Schritt weiter in Richtung Microsoft Fanboy bringt. Diabolisch! Danke Scott Guthrie! Resourcen: Ankündigung von Scott Gutheries Ankündigung auf jQueries Team Blog Scott Hanselmann Tutorial

im folgenden Video wird alles korrekt dargestellt, so wie wir es kennen und täglich erleben. Beim Lösen der Aufgabe ist ASP.NET der klare Geschwindigkeits Sieger. Der zweite Test ist natürlich unseriös. Ein Speak-Friend Entwickler hätte ASP.NET sicher klar an die Spitze gesetzt. [mehr auf Betterwebapp.com ] [via Dariusz quatscht]

Für die Umsetzung einer ,mehrsprachigen Seite, möchten wir für jede Sprache eine eigene Subdomain verwenden. Also: www.domain.org (default Sprache) en.domain.org es.domain.org und noch 30 weitere :-) Beim Wechsel der Sprache erfolgt eine Redirect auf die entsprechende Subdomain. Beim Rederict auf eine andere Domain, geht in ASP.NET die aktuelle Session verloren. Grund, die aktuelle SessionId wird von ASP.NET, sofern nicht "Cookieless", in einem Cookie gespeichert. Per default wird als Cookie Domain, die aktuelle Domain, inklusive der Subdomains definiert. Also für www.domain.org, ist auch die Domain des Cookies: "domain=www.domain.org" Navigiert man also von einer Subdomain zu einer anderen, wird nun ein neues Session-Cookie mit einer neuen SessionId gesetzt. Möchte man dieses verhindern hilft folgender Code: Der Event lässt sich so registrieren: Hier wird die Domain des gesetzten Cookies im Unload Event der Masterpage angepasst. Wichtig ist, das der "Domain" Teil des Cookies auf allen Seiten der Anwendungen korrigiert wird.

Microsoft MVC beschreitet einen alternativen Web Anwendungen mit ASP.NET Webseiten zu entwickeln. Der Name ist Programm, Model, View und Controller werden vollwertige Entitäten. Folgendes Video bietet eine kurze musikalische Einführung :-) Das WebForm Model soll nicht abgelöst werden, sondern lediglich durch eine eigenständig supportete Lösung ergänzt werden. WebForm und MVC Controls (die erst noch entwickelt werden müssen) werden nicht kompatibel sein. Konzepte wie ViewState und den damit verbunden Zugriff auf die vom Benutzer manipulierten Daten über Controls kennt das MVC Framework nicht. Der Einsatz von MS-MVC sollte also nicht Paradigma sein, sondern wohl überlegt. In Szenarien die eine große Anzahl von Benutzerzuständen und unterschiedliche Controls beinhalten ist der klassische WebForms Ansatz, der wahrscheinlich deutlich schnellere Entwicklungsweg. Abzuwarten bleibt auch die Qualität der Visual Studio Integration, bei der Arbeit mit Webdesignern, eines der großen Pluspunkte von ASP.NET. Nicht zu vergessen, das die Trennung von Model, View und Controller auch schon heute mit Webforms zu erreichen ist, wenn auch nur auf logischer Ebene. Interessant ist, das Microsoft Implementierung ist auf den ersten Blick MonoRail (http://www.castleproject.org/) erstaunlich ähnlich ist. Eine Politik und gänzlich anders als in der Vergangenheit (Beispiel NUnit vs. VS Testcases) ist, das auch die Koexistenz und sogar Integration mit dem MonoRail und Castle Development Stack angedacht ist. Nicht nur das Microsoft nun auch zum ersten Mal im .NET Umfeld einen Entwickler eines Open Source Frameworks (Subsonic) auf der Gehaltsliste hat, der auch dafür bezahlt wird, an seinem alten Projekt (mit der gleichen Restriktionsfreien "Mozilla Public License" Lizenz) weiterzuarbeiten, Microsoft hat auch in letzter Zeit ein Reihe von Community Persönlichkeiten, wie Scott Hanselman und Philip Hack angeworgen. Es verspricht also weiter Spass zu machen mit .NET und insbesondere ASP.NET arbeiten zu dürfen. (Unabhängig davon, dass WPF der Hammer ist :-) Mehr Links: Scott Gutherie über MVC (Teil 1) Scott Hanselmann (mit Link auf Screencast) ASP.NET MVC Pipeline

Es lebe die Informationsrevolution. Tausende von wunderbaren OpenSouce Webanwendungen aus allen nur erdenklichen Segmenten warten darauf verwendet  zu werden. Ob ein Content Management System mit hunderten von Komponenten, eine Enterprise fähige Shop-Lösung oder eine Project Management Werkzeug für Entwickler inklusive Versionskontrolsystem Zugriff alles ist verfügbar. Doch wie lange dauert es von der Idee, bis zur Umsetzung? Hier ein einfaches Beispiel. Wir benötigen eine Domain, 2 Email-Accounts, eine Präsentationseite mit CMS Eigenschaften, einen Blog und wir wollen alle Inhalte editieren können. Hier die Zeiten:   Domain registrieren 10min. Emails einrichten 10min. Domain auf Server einrichten 5min OSS Lösung auf Server installieren 30min Anpassung der Lösung: Strukur und Skin anpassen, Übersetzungen pflegen. 1h Benachrichtigungsemail verfassen 25min Fertig :-) Von der Anforderung bis hin zur fertigen Lösung in 2:20h. Na klar, das Scenario ist deutlich das einfachste was ich je erlebt habe. Alles funktionierte „Out-Of-The-Box“. Der Server war schon vorbereitet. Die Datenbanken schon da. Die Backuplösung schnurrt von allein. Firewall und IP-Filter sind eingerichtet. Das OSS Produkt kann alles, was gebraucht wurde und war schon bekannt. Eines der Templates hat für den Zweck vollkommen ausgereicht. Das Logo hat gepasst. Und noch war keine Zeit für Support anfragen :-) Achso und natürlich hat es 2 1/2 Stunden gedauert bis die Domain verfügbar war, aber ich zähle das jetzt mal nicht als Arbeitszeit. Insgesamt eine schöne Erfahrung.