Peter Bucher : Control Entwicklung, Artikel

Artikel: ASP.NET Controls genau nach Vorlage

Peter Bucher — Mon, 10 Nov 2008 19:10:00 GMT

In der aktuellen ASP.NET Professional 10/2008 Ausgabe findet sich ein Artikel von mir über die Benutzung von Templates (Vorlagen) in ASP.NET Controls.
Im Artikel werden die verschiedenen Möglichkeiten besprochen um Controls mit Templates auszustatten.

Wer kein Abonnement von ASP.NET Professional besitzt, trotzdem mal reinschnuppern möchte und meinen Artikel interessant findet, kann sich ein kostenloses Probeabo zukommen lassen (Dort ist der aktuelle Artikel drin).

Events für User- und CustomControls definieren und benutzen

Peter Bucher — Thu, 12 Jun 2008 19:44:00 GMT

In der Welt von ASP.NET gibt es - im Gegensatz zu Classic ASP - ein Eventsystem das in der ASP.NET Engine verwurzelt ist.
Dazugehörend haben viele ASP.NET Controls Events. Das bekannteste ist wohl Button.Click, über diesen Event kann festgestellt werden ob ein bestimmter Button gedrückt wurde, oder nicht.

Nun gibt es ja die Möglichkeit eigene User- und CustomControls zu schreiben.
Diese können mit Events ausgestattet werden, und genau um das geht es hier in diesem Artikel.

Wie funktionieren die Events in ASP.NET?

Grundsätzlich ereignen sich alle Aktionen auf dem Client, bspw. klickt eine Person an einem Computer in dessen Webbrowser auf einen Button.
Danach wird das Formular abgesendet und der Server empfängt dieses.

Der Server leitet den Http-Request (Die Http-Anfrage) an die ASP.NET Engine weiter.
Die Engine findet dann anhand der <Control>.UniqueID (Siehe: Identifizierung von Controls: Control.ID / .ClientID / .UniqueID) das Control zu dem die jeweiligen Daten gehören.

Wenn dieses Control gefunden wurde, leitet die Engine die gesamten POST-Daten (Formulardaten) an das bestreffende Control weiter.
Sind die Daten geändert worden, bzw. befinden sich die Daten in einem erwarteten Zustand, löst das Control den Event aus, ansonsten nicht.

Dies ist die normale Vorgehensweise von Events (Die Page Events laufen ähnlich ab), die über POST (Formular, Postback) ausgelöst werden.

Wie definiere ich einen Event, oder was ist ein Event überhaupt?

Für die Grundlagen zur Event-Erstellung, mit oder ohne nutzerspezifische Argumente, verweise ich hier auf den FAQ Thread des C#-Forums myCSHarp.de.

Eigenen Event definieren / Information zu Events (Externer Link: myCSharp.de)

Die FAQ von myCSharp.de als solches ist auch für andere Sprachspezifische Angelegenheit sehr zu empfehlen.

Wie / Wann werden die Events ausgelöst und gibt es mehrere Auslösearten?

Das trickreiche an Events in ASP.NET ist nicht die Dekleration der Events, sondern der Zeitpunkt an dem sie ausgelöst werden sollen.
Es gibt tatsächlich mehrere Arten von Zustandsveränderungen bei denen ein Event ausgelöst werden kann.

Folgend die Möglichkeiten von Zustandsänderungen durch einen Benutzer der Web Applikation ausgelöst:

Werte die durch einen (oder mehrere) GET-Parameter (QueryString) empfangen werden, bspw. wenn der Benutzer auf einen Link klickt
Werte die durch einen (oder mehrere) POST-Parameter (Form) empfangen werden, bspw. wenn der Benutzer Formularfelder ausgefüllt hat und dann auf einen Button klickt, oder aber nur auf einen Button klickt

Zudem gibt es noch weitere Faktoren und Möglichkeiten, die als Indikatoren für eine Eventauslösung benutzt werden können:

Werte die durch einen (oder mehrere) POST-Parameter empfangen werden, die durch die __doPostback-Javascriptfunktion abgeschickt werden
Zustandsänderungen aller Art auf der Serverseite (Datei, Datenbank, Session, Zeit, Datum, etc...
Festgelegte Logik im Code, bspw. Vergleiche, etc...

Aller Anfang ist ~~schwer~~ leicht

Zuerst folgt ein Beispiel das auf einen GET-Parameter reagiert und bei Vorhandensein des Parameters einen Event auslöst.

C#:

namespace pb.Web.UI.WebControls.Examples { public class TestControlGetSimple : WebControl { public event EventHandler ParameterAvailable; protected virtual void OnParameterAvailable(object sender, EventArgs e) { if (this.ParameterAvailable != null) this.ParameterAvailable(sender, e); } protected override HtmlTextWriterTag TagKey { get { return HtmlTextWriterTag.Div; } } protected override void OnInit(EventArgs e) { base.OnInit(e); HyperLink link = new HyperLink(); link.ID = "hlTest"; link.Text = "Testlink"; link.NavigateUrl = "?test=1234"; this.Controls.Add(link); } protected override void OnLoad(EventArgs e) { base.OnLoad(e); string name = this.Context.Request.QueryString["test"]; if(!string.IsNullOrEmpty(name)) { this.OnParameterAvailable(this, EventArgs.Empty); } } } }

Was genau passiert da jetzt?

Das Beispiel ist einfach aufgebaut. Zuerst wird ein Event mit einem Standard-Eventhandler (in .NET verfügbar) implementiert.
Danach wird die eventauslösende OnEvent-Methode definiert, die aufgerufen wird, wenn der Event ausgelöst werden soll.

Anschliessend wird per überschriebenen TagKey-Eigenschaft angegeben, dass das Control ein umschliessenden Div-Tag besitzen soll. (Im Beispielprojekt wird das für die Formatierung benutzt).
In der OnInit-Methode wird ein Objekt vom Typ Hyperlink angelegt, ein Text und eine Url + GET-Parameter angegeben und anschliessend zum Control hinzugefügt.

Jetzt kommt der spannende Teil: Das Event wird ausgelöst.

Beim Laden des Controls wird ein evt. vorhandener Parameter über <HttpContext>.Request.QueryString(<Key>) abgerufen, und anschliessend überprüft ob dieser null oder ein Leerstring (String.Empty) ist.

Falls dies nicht der Fall ist, wird der Event ausgelöst. Das war schon der ganze "Zauber" auf der Control-Seite.

Die Benutzung des Controls in einer ASP.NET Seite ist sehr einfach und geht so von der Hand, wie ansonsten ein Klick-Event eines Buttons abonniert wird.

Wie das Control registiert wird, um auf der Seite zu benutzen, kann im folgendenen Blogpost nachgelesen werden:

UserControl und CustomControls per web.config verfuegbar machen

Beispiel:

ASPX:

 
<fieldset> 
    <legend>GET Beispiel (simple)</legend> 
    <pb:TestControlGetSimple ID="testGetSimple" runat="server" /> 
    <br /> 
    <asp:Label ID="lblInfoGetSimple" Text="Parameter nicht verfügbar" runat="server" /> 
</fieldset>

Codebehind (C#):

 
protected void Page_Load(object sender, EventArgs e) { 
    this.testGetSimple.ParameterAvailable += testGetSimple_ParameterAvailable; 
} 


void testGetSimple_ParameterAvailable(object sender, EventArgs e) { 
    this.lblInfoGetSimple.Text = "Parameter ist <strong>vorhanden</strong>"; 
}

Zuerst werden auf der ASP.NET Seite das Test-Control und ein Label hinzugefügt.
Anschliessend abonnieren wir das Event im Page_Load Eventhandler und fügen dem zugewiesenen Handler Code hinzu, damit das Label anzeigt, ob der Event ausgelöst wurde oder nicht.

Wenn der Link angeklickt wird und infolgedessen ein GET-Parameter vorhanden ist, wird das Event ausgelöst und im Eventhandler den Text des Labels geändert.
Aus Benutzersicht ist nur der geänderte Text sichtbar.

Das Beispiel wurde mit Absicht sehr simpel gehalten, um einen einfach Einstieg zu ermöglichen.

Ein erweitertes Beispiel mit GET-Parametern

Folgend der Code eines erweiterten Beispiels, das mithilfe einer Session erkennen kann, ob der aktuelle Wert des GET-Parametes geändert wurde. Den ASPX-Teil wird nicht mehr gezeigt, da er praktisch identisch zum Beispiel (Siehe Code) ist.

C#:

 
namespace pb.Web.UI.WebControls.Examples 
{ 
    public class TestControlGet : WebControl, INamingContainer 
    { 
        public delegate void NameChangedDelegate(object sender, NameChangedEventArgs e); 
        public event NameChangedDelegate NameChanged; 


        protected virtual void OnNameChanged(object sender, NameChangedEventArgs e) { 
            if (this.NameChanged != null) 
                this.NameChanged(sender, e); 
        } 

        protected override HtmlTextWriterTag TagKey { 
            get { 
                return HtmlTextWriterTag.Div; 
            } 
        } 

        protected override void OnInit(EventArgs e) { 
            base.OnInit(e); 

            for (int i = 0; i < 5; i++) { 
                HyperLink link = new HyperLink(); 
                link.ID = "testLink" + i.ToString(); 
                link.Text = "Patrick " + i.ToString(); 
                link.NavigateUrl = "?name=Patrick" + i.ToString(); 
                this.Controls.Add(link); 
                this.Controls.Add(new LiteralControl("<br />")); 
            } 
        } 

        protected override void OnLoad(EventArgs e) { 
            base.OnLoad(e); 

            string name = this.Context.Request.QueryString["name"]; 
            string nameBefore; 
            object sessionValue = this.Context.Session["name"]; 

            if (sessionValue != null) 
                nameBefore = sessionValue.ToString(); 

            bool flag = false; 

            // Erste Änderung (ohne Session, erster Aufruf) 
            if (name != null && sessionValue == null) 
                flag = true; 

            // Änderung mithilfe der Session herausfinden 
            if (sessionValue != null && name != null && !sessionValue.Equals(name)) 
                flag = true; 

            if(flag) 
                this.OnNameChanged(this, new NameChangedEventArgs(name)); 

            this.Context.Session["name"] = name; 
        } 
    } 

    public class NameChangedEventArgs : EventArgs { 
        private string _newName; 

        public NameChangedEventArgs(string newName) { 
            this._newName = newName; 
        } 

        public string NewName { 
            get { return this._newName; } 
        } 
    } 
}

In diesem Beispiel wird eine Liste von Links mit GET-Parametern ausgegeben.
Wenn der empfangene Parameter ändert, wird der Event ausgelöst.

Beim ersten Empfangen eines Wertes wird dieser in die Session geschrieben und dieser Spezialfall berücksichtigt.
Wird jedoch ein Wert empfangen, wenn die Session schon ein Wert enthält, wird auf Ungleichheit geprüft, falls wahr wird der Event ausgelöst.

Zudem wird in diesem Beispiel ein eigener Delegate benutzt, um eigene EventArgs zu unterstützen.
Im Eventhandler kann der geänderte Namen einfach über e.NewName abgerufen werden.

(Der Einfachheit halber habe ich keinen generischen EventHandler benutzt, obwohl dieser ab .NET 2.0 natürlich zu empfehlen wäre. Wie es geht, siehe: Eigenen Event definieren / Information zu Events (Externer Link: myCSharp.de) )

Einen Event über POST-Werte mithilfe von IPostBackEventHandler und ClientScript.GetPostBackEventReference auslösen

Wie weiter oben schon angesprochen, stellt ASP.NET selber eine Architektur bereit, um mit POST-Daten Events über eine spezielle Infrastruktur auszulösen.
Die jetzt vorgestellte Lösung basiert auf der __doPostBack-Funktion, die ASP.NET im Normalfall in jeder ASP.NET Seite zur Verfügung stellt.

Folgend die Definition der Schnittstelle.

C#:

 public interface IPostBackEventHandler 
{ 
    void RaisePostBackEvent(string eventArgument); 
}

Im Normalfall geschieht ein Postback über einen Html-Button, der das Formular absendet.
Das Formular kann aber auch per Javascript abgesendet werden, genau das nutzt die __doPostBack-Funktion.
Sie kann zusätzlich Parameter entgegennehmen und diese über HiddenFields (Versteckte Eingabefelder) zum Server schicken.

So ist nicht nur ein Abschicken und Prüfen von Form-Elementen möglich, sondern auch das übergeben beliebiger Elemente und zudem auch den Namen des Controls, von dem die Elemente bzw. Argumente kommen.

Über die Methode GetPostBackEventReference() der Klasse ClientScript finden sich viele Überladungen, die benutzt werden können um eine Javascript Postback-Referenz zu bekommen.
Dies ist nichts weiter als ein benutzerdefinierter Aufruf der __doPostBack-Funktion, mit eigenen Parametern.

ASP.NET stellt eine Schnittstelle Namens IPostBackEventHandler zur Verfügung, die implementiert werden kann, um über Postbacks mit der Möglichkeit der Übergabe von Elementen zu kommunizieren.
Dabei muss immer das Control selber (schlussendlich die UniqueID des Controls) übergeben werden, sowie Argumente nach Wunsch.

Vielleicht kennt der eine oder andere die __doostBack-Funktion aus dem GridView, wenn eine Zeile selektiert wird.
Dies wird genau nach diesem Schema erledigt.

Folgend nun das Beispiel (Wiederum nur das Control an sich, da der Rest praktisch gleich ist):

C#:

 
namespace pb.Web.UI.WebControls.Examples 
{ 
    public class TestControlPost : WebControl, INamingContainer, IPostBackEventHandler 
    { 
        public delegate void NameSelectedDelegate(object sender, NameSelectedEventArgs e); 
        public event NameSelectedDelegate NameSelected; 


        protected virtual void OnNameChanged(object sender, NameSelectedEventArgs e) { 
            if (this.NameSelected != null) 
                this.NameSelected(sender, e); 
        } 

        protected override HtmlTextWriterTag TagKey { 
            get { 
                return HtmlTextWriterTag.Div; 
            } 
        } 

        protected override void OnInit(EventArgs e) { 
            base.OnInit(e); 

            for (int i = 0; i < 5; i++) { 
                HyperLink link = new HyperLink(); 
                link.ID = "testLink" + i.ToString(); 
                link.Text = "Patrick" + i.ToString(); 
                link.NavigateUrl = "#"; 
                link.Attributes.Add("onclick", this.Page.ClientScript.GetPostBackEventReference(this, "Patrick " + i.ToString())); 
                this.Controls.Add(link); 
                this.Controls.Add(new LiteralControl("<br />")); 
            } 
        } 

        #region IPostBackEventHandler Members 

        public void RaisePostBackEvent(string eventArgument) { 
            if(this.NameSelected != null) 
                this.NameSelected(this, new NameSelectedEventArgs(eventArgument)); 
        } 

        #endregion 
    } 

    public class NameSelectedEventArgs : EventArgs 
    { 
        private string _selectedName; 

        public NameSelectedEventArgs(string newName) { 
            this._selectedName = newName; 
        } 

        public string SelectedName { 
            get { 
                return this._selectedName; 
            } 
        } 
    } 
}

Das Beispiel ist dem letzten Beispiel sehr ähnlich, jedoch geht es hier um das Selektieren eines Namens, nicht um die Änderung dessen.

Es werden auch HyperLinks erzeugt, und in dessen clientseitigem onclick-Eventhandler jeweils die PostBackEvent-Referenz mithilfe obengenannter Methode ein parameterisierter Javascript-Aufruf für das jeweilige Link erzeugt.
Dabei wird eine Referenz auf das Control selbst mitgegeben, damit ASP.NET das Control anhand der UniqueID identifizieren kann, und den Namen, der selektiert werden kann.

Die ASP.NET Engine merkt beim Durchgehen aller Controls, dass dieses Control die IPostBackEventHandler Schnittstelle implementiert und feuert dann ggf. bei Bestehen eines Events dass durch das Link gesendet wurde, das Event.

Dies geschieht dadurch, dass ASP.NET die Methode RaisePostBackEvent aufruft und ihr das Argument übergibt, dass vom Client gesendet wurde.
Aufgrund dieser Infos kann schlussendlich im Eventhandler auf das Argument zugegriffen werden.

Das Interface IPostBackDataHandler, Sinn und Nutzen

ASP.NET stellt noch ein weiteres Interface zur Verfügung, um Events auszulösen.
Dieses setzt zwei Methoden voraus, folgend die Definition:

C#:

 public interface IPostBackDataHandler 
{ 
    bool LoadPostData(string postDataKey, NameValueCollection postCollection); 
    void RaisePostDataChangedEvent(); 
}

Im Beispiel auf der Seite von Microsoft, ist ein ziemlich sinnloses Beispiel zu finden, indem von einem WebControl ein Button nachgebaut wird.

Diese Schnittstelle wird nur existieren, damit Microsoft alle Form-Controls implementieren konnte.
In LoadPostData werden die UniqueID des Controls selber und die komplette Post-Collection angeboten.

Durch <Collection>[postDataKey] kann der Wert des Controls sehr einfach gelesen werden, der Rückgabetyp ist ein bool und bei einer Rückgabe von true wird die RaisePostDataChangedEvent()-Methode aufgerufen und der oder die Events können gefeuert werden.
ASP.NET ruft - auch durch die Interface-Markierung - jeweils die Methode LoadPostData automatisch auf.
Dies jedoch nur, wenn als TagKey bzw TagName des Controls ein bekanntes Form-Control gesetzt ist (Was auch Sinn macht).
Wenn die Methode bei einem eigenen Control trotzdem aufgerufen werden soll, so muss die Methode RegisterRequiresPostBack (Siehe auch: Understanding what Page.RegisterRequiresPostBack does) von der Klasse Page aufgerufen werden und das zu registrierende Control übergeben werden.

Für eine Implementation der Controls: Button, DropDownList, TextBox, etc... ein sehr sinnvolles Interface.
Bei der Implementation eines eigenen Controls, das kein Form-Tag darstellt geht es m.E. einfacher und besser ohne dieses Interface.

Siehe auch:

http://www.dotnetjunkies.com/WebLog/srivallichavalidotnet/archive/2005/11/14/133754.aspx

An dieser Stelle gibt es kein Beispiel, jedoch ist im Download auch ein solches Beispiel vorhanden, dass das Interface benutzt.

Inhalt des Downloads:

Alle hier darstellten Beispiele
IPostBackDataHandler-Beispiel
Alles in einer Solution mit einem Control-Library Projekt und einem Web Application Project zum Testen

Download:

Control Events Sample

Dank geht an:
Norbert Eder für das Review des Artikels

Ich freue mich über jegliche Kommentare!

Artikel: StyleSwitcher selbst gemacht

Peter Bucher — Wed, 28 May 2008 17:15:00 GMT

In der aktuellen ASP.NET Professional 05/2008 Ausgabe findet sich ein Artikel von mir über das StyleSwitcher-Control.
Im Artikel finden sich Informationen über das Innere des Controls, die Überlegungen dazu und die Implementation wird Schritt für Schritt erklärt.

Update:

Der Artikel steht jetzt zum Download zur Verfügung.

Bearbeitungen / Korrekturen:

13.01.09 - Downloadlink zum Online Artikel hinzugefügt

Ein simples Listen Menü mit ASP.NET

Peter Bucher — Tue, 01 Apr 2008 17:18:00 GMT

Das mitgelieferte Menü Control von ASP.NET rendert Tabellen und vieles unnötiges Markup.
Mit den CSS Adapters wird das ganze zwar ausgebogen, erfordert aber eine Installation bzw. Einrichtung im Projekt und ist vielen (auch mir) nicht so symphatisch.

Nicht nur aus oben genanntem Grund, sondern auch weil es eine suboptimale Lösung darstellt, der generierte Markup der Adapters ist m.E. auch noch nicht optimal.

Ein Menü braucht ja jeder, und korrektes und einfaches Markup ist beim Menü noch viel wichtiger, als dies bei anderen Seitenteilen der Fall ist.
Im Prinzip liefert ASP.NET schon ein ~~komplettes~~ fast komplettes Menü mit, ohne es danach zu Benennen ;-)

Ich meine damit das "BulletedList" Control. Wenn dieses leicht abgeändert wird, wird daraus ein super funktionales Menü, das deklerativ, per Code oder sogar per DataBinding mit Daten gefüllt werden kann.

Natürlich hat dieses Control dann die Beschränkung auf eine Dimension, doch vielfach reicht dies aus.
Ansonsten muss die ganze Gschicht dann auf einer anderen Basis aufgebaut werden.

Genug der Worte, sehen wir uns den Code an...

web.config (Beispiel siehe hier, geht aber auch in der Seite selber, für eine Seite):

<add tagPrefix="pb" namespace="pb.Web.UI.WebControls" assembly="ListMenuTest"/>

ASPX:

<pb:ListMenu ID="testMenu" runat="server">
    <asp:ListItem Text="Home" Value="?url=1" />
    <asp:ListItem Text="Produkte" Value="?url=2" />
    <asp:ListItem Text="Kontakt" Value="?url=3" />
    <asp:ListItem Text="FAQ" Value="?url=4" />
</pb:ListMenu>

Ein bisschen CSS:

 #testMenu {
 list-style-type: none;
 border: 1px dotted gray;
 padding: 15px;
 width: 200px;
} 


#testMenu a {
    font-family: Tahoma;
    font-size: 1.5em;
    font-style: oblique;
    color: Black;
    border-left: solid 20px #878787;
    padding-left: 4px;
    
    text-decoration: none;
}

#testMenu a.active,
#testMenu a:hover {
    border-left: solid 20px #000446;
    padding-left: 4px;
    color: #878787;
}

Test Code für das Beispiel im Codebehind der Testseite:

protected void Page_Load(object sender, EventArgs e) {
    string activeValue = this.Request.QueryString["url"] as string;
    if (activeValue != null)
        this.testMenu.ActiveValue = "?url=" + activeValue;
}

Das Control selber:

 

using System;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace pb.Web.UI.WebControls
{
    public class ListMenu : BulletedList
    {
        private string _activeValue;
        public string ActiveValue {
            get { return this._activeValue; }
            set { this._activeValue = value; }
        }

        protected override void RenderContents(HtmlTextWriter writer) {
            foreach (ListItem item in this.Items) {
                writer.WriteFullBeginTag("li");
                writer.AddAttribute("href", item.Value);
                if (item.Value == this._activeValue) {
                    writer.AddAttribute("class", "active");
                }
                writer.RenderBeginTag("a");
                writer.Write(item.Text);
                writer.RenderEndTag();
                writer.WriteEndTag("li");
                writer.Write(Environment.NewLine);
            }
        }
    }
}

Wie man sehen kann, nehme ich das BulletedList Control, füge eine neue Eigenschaft "ActiveValue" hinzu und nehme das Rendering des Contents (Alle innenliegenden <li>-Tags) selber in die Hand.
Hierbei wird dem aktiven Item jeweils die CSS Klasse "active" zugewiesen.

Zuweisung der Styles erfolgt hier jetzt über die ID, die ID kann sich - je nach Gegebenheit - aber ändern, das heisst am besten eine Klasse dafür nehmen, oder über das umschliessende Div ansprechen.

Thats it, viel Spass damit!

Beispielanwendung gibts hier zum Download

UserControl und CustomControls per web.config verfuegbar machen

Peter Bucher — Thu, 27 Sep 2007 17:55:00 GMT

In grösseren Projekten sammeln sich im optimalen Fall natürlich auch eine grosse Menge an Controls an. Diese müssen im Normallfall per Register Direktive in jeder ASPX Seite registriert und somit verfügbar gemacht werden. Es ist ab ASP.NET 2.0 aber auch...(read more)

CheckBoxListValidator - CheckBoxList validieren

Peter Bucher — Wed, 22 Aug 2007 21:57:00 GMT

Ich hatte neulich die Anforderung ein CheckBoxList Control zu validieren. Mit den Validatoren die mit ASP.NET mitkommen, lässt sich da nichts machen ausser dem Einkassieren einer Exception. Das ist auch gut so, denn diese sind nicht dafür gedacht. Es...(read more)

Ressourcen in CustomControl Assembly einbetten und benutzen

Peter Bucher — Sun, 15 Jul 2007 21:54:00 GMT

Einführung
Bei einem etwas umfangreicheren CustomControl kommt man schnell an die Grenzen.
Es werden zusätzlich zu reinen Textausgaben, vielfach auch Ressourcen gebraucht,
diese können in Form von Text sein, wie z.B. Javascript oder CSS, aber auch binäre Daten, wie z.B. Bilder oder ZIP Dateien.

Seit ASP.NET 2.0 gibt es die Möglichkeit, Ressourcen relativ einfach einzubinden, und zugleich in die Assembly mit zu kompilieren.
Das heisst, die DLL für das Control enthält zugleich die Ressourcen die es benutzt.
Das Deployment wird dadurch klarer und einfacher, die Ressourcen sind in der DLL gekapselt und können nicht einfach so ausgetauscht werden.
Somit kann auch das Problem vermieden werden, eine andere Version der Ressource mitzuliefern.

In ASP.NET 2.0 gibt es eine spezielle Url (WebResource.axd), die von der Engine genutzt wird, um dieses Feature umzusetzen.
Über diese Url und zwei automatisch zugewiesenen Parametern (Assembly Key / DateTime of last Assembly write) kann die Ressource abgerufen und benutzt werden.
Das ist vor allen Dingen für CSS und Javascript sehr interessant.
Anstelle von Javascript Code der im Code eingebettet und per Page.ClientScript.RegisterClientScriptBlock() registriert wird, legen wir in unserem Projekt eine normale Javascript Datei an.
Diese Datei wird als eingebettete Ressource markiert und dann per Code als externe Url in Empfang genommen.

Die Idee für das Beispielprojekt habe ich mir über zwei Ecken von Michal geholt, und den Javascript Code 1:1 übernommen.
Es wird ein CustomControl implementiert, das sich selber bei Bedarf vergrössert und als Textarea gerendert wird.
Damit haben wir nicht eine unnötig grosse Textarea auf der Seite, und den ganzen Text immer im Blickfeld.

Einbettung und Registrierung der Ressource in die Assembly
Eine Ressource (z.B. Javascript oder CSS) kann direkt als Datei in das CustomControl Projekt eingefügt werden.
Im Beispielprojekt erstellen wir eine Javascript Datei im Solution Explorer und markieren diese als eingebettete Ressource.
Dies bewirkt dass die Ressource beim kompilieren in die resultierende DLL eingebettet wird.

Die Ressource muss in der AssemblyInfo.cs registriert werden, damit wir über den Webresource.axd HTTP Handler darauf zugreifen können.
Unter "Properties" im Solution Explorer und dem betreffenden Projekt, liegt die AssemblyInfo.cs, in dieser müssen wir ein zusätzliches Attribut nach folgender Konvention hinzufügen.

[assembly: WebResource("<Root Namespace>.<Dateipfad>", "<ContentType>")]

Im Falle des Beispielprojekts ergibt sich folgendes Attribut:

[assembly: WebResource("t4m.Controls.AutoResizingTextarea.js", "text/javascript")]

Update:

In VB.NET gibt es die Option einen "Rootnamespace" bzw. "Stamm Namespace" anzugeben, oder auch nicht.
Wenn dieser leer ist, darf _nur_ der Dateiname der Ressource angegeben werden.

Andernfalls [Stamm Namespace].[Dateiname]

VB.NET kann nicht mit Pfaden umgehen, daher müssen alle Ressourcen jeweils einen anderen Dateinamen in derselben Assembly haben,
ansonsten wird die Assembly nicht erstellt.

Zitat aus (CodeProject Artikel [Kommentar]):

c# way:
[Default namespace].[PathToTheResource].[ResourceName]

vb.net way:
If you have empty namespace: [ResourceName] Nothing more nothing less!!!
You have a given root namespace: [Default namespace].[ResourceName] No path at all!!!

So vb.net doesn't (cannot?) use the path, this means: if you have two resource with same name in different place in your solution the project won't build!

Eine Angabe in VB.NET kann in der Controlklasse erfolgen, sowie auch in der AssemblyInfo.vb.
Beides funktioniert, allerdings wäre der Weg über die AssemblyInfo.vb wohl sauberer.
Ein solches Attribut kann folgendermassen aussehen:

<Assembly: WebResource("MeineRessource.js", "text/javascript")>

(Damit die AssemblyInfo.vb sichtbar wird, muss im Solution Explorer die Option "Alle Dateien anzeigen" gewählt werden!)

Benutzung der Ressource im CustomControl
Über die ClientScriptManager Instanz und dessen Methode "GetWebResourceUrl" kann die Url zur Ressource abgerufen werden.
Mit der Methode "RegisterClientScriptInclude" des ClientScriptManagers und der Url wird die Ressource als externes Javascript eingebunden, und ist somit auf der aktuellen Seite verfügbar.

In der überschriebenen Methode "AddAttributesToRender" hängen wir ein "onkeyup" Eventhandler mit einem parameterisierten Funktionsaufruf als Attribut für die Textarea hinzu.

protected override void AddAttributesToRender(HtmlTextWriter writer)
{
    string attributeString = String.Empty;
    bool addAttributes = true;
    
    if(this._minRows != 0 && this._minCols != 0) {
        // Zeilen und Spalten resizen
        attributeString = "resizeTextArea(this, " + this._minCols.ToString() + ", "
                          + this._minRows.ToString() + ");";
    } else if(this._minCols != 0) {
        // Nur Zeilen resizen
        attributeString = "resizeTextArea(this, "
                          + this._minCols.ToString() + ");";
    } else {
        addAttributes = false;
    }
    
    if(addAttributes)
        writer.AddAttribute("onkeyup", attributeString);
    
    base.AddAttributesToRender(writer);
}

Im überschriebenen OnPreRender des Controls wird das Include per ClientScriptManager registriert.
Die Methode "RegisterClientScriptInclude" erwartet einen Schlüssel und die Url der Resource.
Die Parameter der "GetWebResourceUrl" Methode sind jeweils der Typ der Assembly und den Ressourcennamen (der selbe wie in AssemblyInfo.cs).

 
protected override void OnPreRender(EventArgs e)
{
    if (this.Page != null)
    {
        ClientScriptManager manager = this.Page.ClientScript;
        manager.RegisterClientScriptInclude("AutoResizingTextArea",
                                            manager.GetWebResourceUrl(this.GetType(),
                                                                      "t4m.Controls.AutoResizingTextarea.js"));
    }
    
    base.OnPreRender(e);
}

Mithilfe der "RegisterClientScriptInclude" Methode wird der Javascript Include Tag nur einmal und inmitten der Seite bzw. genau oberhalb des ersten Controls gerendert.
Das ist ein wenig unschön. Das Include kann aber auch in den Head Tag gerendert werden, jedoch in Eigenregie.
Über die ID und vorangehende Prüfung auf ein Control in der Hierarchie wird vermieden, dass das Include bei mehr als einem Control des gleichen Typs mehrfach gerendert wird.
Diese Überprüfungsarbeit wird uns im oberen Fall mit "RegisterClientScriptInclude" abgenommen, aber die Prüfung auf die ID ist nicht aufwändig und funktioniert.

if (this.Page.FindControl("AutoResizingTextArea") == null)
{
    string jsUrl = this.Page.ClientScript.GetWebResourceUrl(this.GetType(), "t4m.Controls.AutoResizingTextarea.js");
    HtmlGenericControl link = new HtmlGenericControl("script");
    link.ID = "AutoResizingTextArea";
    link.Attributes.Add("type", "text/javascript");
    link.Attributes.Add("src", jsUrl);
    this.Page.Header.Controls.Add(link);
}

Die Ausgabe des Javascript Includes sieht dann z.B. so aus:

</script src="http://www.aspnetzone.de/WebResource.axd?d=mKz7Vb-Q8_bkDUZyl5AYY8EyVDVf_p6szFgppsuGhxxVgB7LsNffB2soCdnTCu7p8Y2KMjUlABwuU4ycvynCQw2&amp;t=633201523485135647" type="text/javascript">

Quellen und weiterführende Links:

Beispielprojekt:

EmbeddedResourcesTest

Bearbeitung / Korrekturen:
26.06.08 - Update für VB.NET

SelfValidatingControl - CustomControl selber validieren lassen

Peter Bucher — Thu, 21 Jun 2007 22:24:00 GMT

Ich bin in der Newsgroup über die Frage gestolpert, wie man ein sich selbst validierendes Control, ohne ein zusätzliches Custom Validator Control dazu bringen kann, die Eigenschaft IsValid von der aktuellen Page Instanz zu beeinflussen.

Nun, wenn man ein bisschen nachforscht, findet man in der MSDN oder aber dem Reflector die abstrakte Basisklasse BaseValidator.

Folgend die Definition dieser Basisklasse:

public abstract class BaseValidator : Label, IValidator

Eine Klasse die von BaseValidator erbt, so wie das bei allen Validator Controls ausser der ValiationSummary der Fall ist, erben also von Label und implementieren das Interface IValidator.
Okay, für einen Validator an sich, mag es sinnvoll sein, sich wie ein Label zu verhalten, denn wir wollen schliesslich eine Fehlermeldung ausgeben.
In einem CustomControl sieht das aber wieder anders aus, vorallem dann, wenn wir die Validation selber erledigen.

Man kann / könnte die benötigten und schon im Framework vorhandenen Validatoren zu seinem CustomControl hinzufügen, und schliesslich auch veranlassen, dass diese Validatoren bei der Seitenüberprüfung berücksichtigt werden.
Jedoch geht es m.E. leichter von der Hand, wenn man sein CustomControl validationsfähig macht, und die einzelnen Prüfungen, sowie auch die Fehlerausgabe im Control selber erledigt.

Ich möchte euch anhand eines einfachen uns ziemlich sinnfreien Beispiels zeigen, wie man so etwas implementieren könnte.
Eine Klasse das als Validator fungieren möchte, muss das Interface (Schnittstelle) IValidator implementieren, als Basisklasse wählen wir in diesem Fall Control, da wir kein einzelnes Haupt Element brauchen.
Definition unseres CustomControls:

public class SelfValidatingControl : Control, IValidator

Als nächstes definieren wir die benötigten privaten Felder.
_isValid brauchen wir als Hilfsvariable im Zusammenspiel mit der Validierung.

private bool    _isValid = false;
private TextBox _txtSurname;
private TextBox _txtName;

Und jetzt geht es an die Implementation des CustomControls, hierzu erstellen wir im Konstruktor zwei TextBoxen und fügen sie zur Controls Collection hinzu.
Zwischen die TextBoxen schieben der Einfachheit halber, LiteralControls, jeweils mit "Vorname", "Name" und den dazugehörigen Breaks dazu "<br />".

public SelfValidatingControl() {
    this._txtSurname = new TextBox();
    this._txtName    = new TextBox();
    
    this.Controls.Add(new LiteralControl("Vorname:"));
    this.Controls.Add(new LiteralControl("<br />"));
    this.Controls.Add(this._txtSurname);
    this.Controls.Add(new LiteralControl("<br />"));
    this.Controls.Add(new LiteralControl("Name:"));
    this.Controls.Add(new LiteralControl("<br />"));
    this.Controls.Add(this._txtName);
}

Jetzt fehlen noch zwei wichtige Dinge:

Implementation der IValidator Schnittstelle
Weitergabe des Validators an die Validator Collection der aktuellen Page Instanz

Wenn wir die Schnittselle in der Klassendefinition niederschreiben, gibt uns Visual Studio die Möglichkeit, automatisch ein Grundgerüst für diese Schnittstelle zu erstellen. Nette Sache, machen wir :-)
Die Eigenschaft "ErrorMessage" müssen wir implementieren, benutzen sie in diesem Fall aber nicht, deshalb ist auch der Setter leer.
Bei der Eigenschaft "IsValid", geben wir den aktuellen Status anhand der Instanzvariable "_isValid" zurück, oder ändern diese.
In der Validate Methode, wird die Validierung ausgeführt, und die Instanzvariable "_isValid" bei Erfolg auf true, und bei Misserfolg auf false gesetzt.
Im konkreten Fall überprüfen wir nur, ob beide TextBoxen nicht leer sind, thats it.

 
#region IValidator Members 


public string ErrorMessage
{
    get
    {
        return "Surname or Name empty";
    }
    set { ; }
}

public bool IsValid
{
    get
    {
        return this._isValid;
    }
    set
    {
        this._isValid = value;
    }
}

public void Validate()
{
    if (this._txtSurname.Text != String.Empty
       &&
       this._txtName.Text != String.Empty)
    {
        this._isValid = true;
    } else {
        this._isValid = false;
    }
}

#endregion

Und jetzt kommt der ganze Clou an der Sache.
Wenn wir auf der aktuellen Page den Status per Page.IsValid abfragen, durchläuft die aktuelle Page Instanz ihre Validator Collection.
Unser Control muss dort jetzt natürlich rein, da es, ausser einem Control, zusätzlich auch noch die Rolle eines Validators eingenommen hat.
Dies erledigen wir, indem wir die OnInit Methode des Controls überschreiben und dort auf die aktuelle Page Instanz Zugreifen.
Über die .Add Methode der Validator Collection, fügen wir über "this", die aktuelle Instanz unserer Control Klasse hinzu, also das Objekt, in dem wir uns im Moment befinden.

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
    this.Page.Validators.Add(this);
}

Auf der einer beliebigen Seite müssen wir nur noch unser Control deklerativ oder per Code einfügen.
Ab diesem Moment ist die Page.IsValid Eigenschaft auch auf den Zustand dieses Controls sensibel.

Beispielprojekt:

SelfValidatingControlTest

Quellen:

Entwickeln eines Bestätigungssteuerelements (MSDN)

Von WebControl abgeleitetes CustomControl - Haupt Html Element festlegen

Peter Bucher — Thu, 31 May 2007 21:59:00 GMT

Wenn man ein CustomControl mit ASP.NET entwickeln will, leitet man in den meisten Fällen von WebControl ab.

Zitat aus einem MSDN Artikel: Entwickeln und Verwenden eines benutzerdefinierten Serversteuerelements

Wenn das Steuerelement ein Element der Benutzeroberfläche (UI) oder ein anderes auf dem Client sichtbares Element rendert, sollten Sie das Steuerelement von System.Web.UI.WebControls.WebControl (oder einer davon abgeleiteten Klasse) ableiten. Falls das Steuerelement ein Element rendert, das im Clientbrowser nicht sichtbar ist, z. B. ein ausgeblendetes Element oder ein meta-Element, leiten Sie das Steuerelement von System.Web.UI.Control ab. Die WebControl-Klasse ist von Control abgeleitet und fügt formatbezogene Eigenschaften hinzu, z. B. Font, ForeColor und BackColor. Zusätzlich kann ein von WebControl abgeleitetes Steuerelement die Designfeatures von ASP.NET nutzen, ohne dass für Sie zusätzliche Arbeit entsteht.

Standardmässig wird bei einer Ableitung von WebControl ein Span-Tag als Hauptelement gerendert, dieses Element enthält unter anderem die ClientID des Controls als ID-Attribut.
In den meisten Fällen möchten wir einen anderen Tag als Grundlage verwenden, bspw. einen Div-Tag.

Erklären lässt sich dieses Verhalten, wenn wir einen Blick auf die Implementierung von der Klasse WebControl werfen.
Der Standardkonstruktor ruft den zweiten Konstruktor auf, und übergibt diesem ein HtmlTextWriterTag.Span mit:

 
protected WebControl() : this(HtmlTextWriterTag.Span)
{
}

Für diesen Fall habe ich im Internet ein "Workaround" gefunden, bei dem man die Methoden RenderBeginTag() und RenderEndTag() überschreibt.
Das Haupt Html Element rendert man inklusive der Unterelemente dann in einer überschriebenen Render() Methode.

Das sieht dann so aus:

public override void RenderBeginTag(HtmlTextWriter writer) {
   // do nothing
} 


public override void RenderEndTag(HtmlTextWriter writer) {
   // do nothing
}

Diese Sache funktioniert auch wunderbar, jedoch hat das auch ein paar Nachteile bzw. die nächste Variante, Vorteile.

Wir nutzen eine eigene Konstruktion, nicht die bequemen Vorgaben von WebControl
Die Methoden AddAttributesToRender(), RenderBeginTag(), RenderContents() und RenderEndTag() werden überflüssig und nicht mehr nutzbar
Es muss mehr geschrieben werden, obwohl es einfacher gehen würde

Intern sieht die Render() Methode von WebControl, die wir ansonsten ja überschreiben, ungefähr so aus:

protected internal override void Render(HtmlTextWriter writer)
{
    this.RenderBeginTag(writer);
    this.RenderContents(writer);
    this.RenderEndTag(writer);
}

Das heisst, wenn das Control mit Render() gerendert wird, werden diese drei Methoden hintereinander aufgerufen.
Diese Aufrufe passieren automatisch, darum müssen wir uns nicht kümmern, so ist es natürlich bequem zu handhaben.

Erstellen einer Klasse die von WebControl abgeleitet ist
Im Konstruktor den Basis Konstruktor aufrufen und einen TagNamen für das Control mitgeben
AddAttributesToRender() Methode überschreiben und mit unseren Attributen füllen
Die RenderContents() Methode überschreiben und unsere Inhalte rendern lassen

Wie man sieht, ist hier ein schöner Ablauf in Methoden und Methodenaufrufen gegliedert.
Der eigentliche Clou liegt darin, den HtmlWriterTag Enumerationswert im Basiskonstruktor mitzugeben.
Um einen Div Tag als Haupt Html Element für sein Control möchte, kann dieser Konstruktor so aussehen:

// Möglichkeit 1, HtmlTextWriterTag Enum Wert übergeben
public MyControl() : base(HtmlTextWriterTag.Div) {
}
// Möglichkeit 2, String übergeben
public MyControl() : base("div") {
}

Die zweite Möglichkeit kann man für Tags nutzen, die nicht in der Enumeration vorhanden sind.
Wenn man AddAttributesToRender() überschreibt, kann man Attribute an das Haupt Html Element hängen.
Das kann z.B. ein onclick Attribute sein:

protected override void AddAttributesToRender(HtmlTextWriter writer) {
   writer.AddAttribute(HtmlTextWriterAttribute.Onclick, "alert('Klappt :-)');");
   base.AddAttributesToRender(writer);
}

In RenderContents() rendern wir den Inhalt, und fertig ist unser Render Grundgerüst für das CustomControl.

Fazit:
Wie man sieht, bietet ASP.NET ein super Modell, um die Entwicklung von Controls zu erleichtern. Das Modell ist m.E. logisch und verständlich aufgebaut.
Um das Modell dahinter noch besser zu verstehen, sollte man die .NET Implementation mit dem Lutz Roeders .NET Reflector genauer anschauen, heisser Tipp! :-)

Ein Codebeispiel folgt...

WaitButtonControl - Auf langes Postback warten

Peter Bucher — Thu, 31 May 2007 21:56:00 GMT

Wieder einmal (wie immer :-), wurde ich durch eine Frage im Forum angeregt.
Es ging darum, einen Button zu haben, der nach dem Klicken sofort deaktiviert wird, einen Hinweistext darstellt und trotzdem noch ein normales PostBack inkl. "Absenderadresse" versendet.

Die Lösung war am Ende folgende (Im Page_Load bspw.):

this.<Button>.Attributes.Add("onclick", "this.disabled = true; this.value = 'Bitte warten...'; " + ClientScript.GetPostBackEventReference(<Button>, null));

Nun gut, es funktioniert, ist relativ schnell geschrieben - aber:

Man muss es trotzdem immer wieder schreiben
Es ist schlussendlich Code, der das Gesamtbild aufbläht
Wenn man eine zusätzliche Funktionalität möchte, muss man es überall nachtragen
Schlussendlich endet das in der Copy&Paste Hell ;-)

Genau für so etwas ist ein ASP.NET CustomControl sehr gut geeignet.
Es folgt der Quellcode des Controls und ein Beispiel zum Herunterladen und Probieren.

WaitButton.cs

using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.ComponentModel; 



namespace t4m.Controls
{
    [DefaultProperty("WaitText")]
    public class WaitButton : Button
    {
        private const string DefaultWaitText = "Bitte warten...";

        private bool _wait       = true;
        private string _waitText = DefaultWaitText;

        public bool Wait {
            get { return this._wait; }
            set { this._wait = value; }
        }

        public string WaitText {
            get { return this._waitText; }
            set { this._waitText = value; }
        }

        protected override void AddAttributesToRender(System.Web.UI.HtmlTextWriter writer)
        {
            if (this._wait)
                writer.AddAttribute("onclick",
                    "this.disabled = true;" +
                    "this.value    = '" +
                    (this._waitText == DefaultWaitText ? DefaultWaitText : this._waitText) +
                    "';" +
                    Page.ClientScript.GetPostBackEventReference(this, null));

            base.AddAttributesToRender(writer);
        }
    }
}

Beispielprojekt:

WaitButton Test Projekt

Weiterführende Links: