.NET, Archive, ASP.NET, aspNETserve, C#

An Embedded ASP.NET Web Server

To correspond with the release of aspNETserve version 1.1, I have written a simple demonstration of hosting an ASP.NET 2.0 web server right into your own application.

The following code sample is about as simple as it gets.

using System; using System.Collections.Generic; using System.Text; using aspNETserve; namespace ConsoleWebServer { class Program { static void Main(string[] args) { string physicalPath = "c:\\wwwroot"; int port = 8080; using (Server s = new Server(new System.Net.IPAddress(new byte[] { 127, 0, 0, 1 }), "/", physicalPath, port)) { s.Start(); Console.WriteLine("Press any key to stop the server"); Console.ReadKey(); s.Stop(); } } } } read more

.NET, Archive, C#

Tail Recursion Revisited

A year ago I blogged about Tail Recursion in C# on .NET 2.0. With the public beta of .NET 3.5 now available, I decided to retry my little experiment.

For the experiment I used Beta 1 of .NET 3.5 (version 3.5.20404), which you can get from here. Using the supplied compiler, I compiled the following C# code:

public class TailTest{ public static void Main(){ TailTest f = new TailTest(); f.DoTail(0); } public void DoTail(int n){ int v = n + 1; System.Console.WriteLine(v); DoTail(v); } } read more

.NET, Archive, C#

Throwing More Than Just Exceptions

Jason / January 23, 2007

It is a little known fact (and probably for the best) that the CLR can throw and catch more than just System.Exception and its children. In fact, the CLR can use any type as if it was an Exception.

.assembly ExceptionTestAssembly {}

.class public ExceptionTest { //custom class
//note that ExceptionTest does NOT extend System.Exception
.method public void .ctor(){
.maxstack 1

.method static void main() il managed{
.entrypoint //program entry point...
.try {
newobj instance void ExceptionTest::.ctor()
throw //throw a random object

} catch ExceptionTest { //catch the random object
ldstr "Random object caught"
call void [mscorlib]System.Console::WriteLine(string)
leave.s OUT

OUT: ret
read more

.NET, Archive, ASP.NET, C#

Cookie Renaming in ASP.NET

Jason / January 20, 2007

In ASP.NET you can seamlessly rename cookies on the fly with the help the PreSendRequestHeaders and BeginRequest events of the HttpApplication class.

Both events call EventArgs delegates, with the sender object as a HttpApplication instance.


/// Called when a cookie is about to be sent to the browser. /// private void CookieOut(object sender, EventArgs e) { HttpApplication app = (HttpApplication)sender; HttpCookie cookie = app.Response.Cookies["ASP.NET_SessionId"]; if (cookie != null) { app.Response.Cookies.Remove("ASP.NET_SessionId"); cookie.Name = "fooBar"; app.Response.Cookies.Add(cookie); } } read more

.NET, Archive, Visual Studio

Accessing XML Comments At Runtime

I have wondered for a long time how to access a Types XML comment data at run-time. I know that comments are normally thrown away in languages, but I figured that .NET must keep the XML comments around somewhere, how else could they display the information through intellisense for user created DLLs.
Well, according to this article that I just found, the XML comments are thrown away like all other comments at compile time.
It seems that intellisense attempts to load a separate .XML file to display the comments. read more

.NET, Archive, C#

Tail Recursion

It appears that the CLR supports proper tail recursion.
Normally when a function is called, a new frame is created on the stack. This can cause problems when too many stack entries are created, resulting in a stack overflow.
Fortunately their is an ingenious solution to this problem, called proper tail recursion. Something is tail recursive if it calls itself as the very last operation before it returns. If not implemented properly, a compiler (or run-time) will still produce stack frames, and could eventually produce an overflow.
Since the recursive call was the last thing the function performed, there is no real reason to return to it. Because of this, there is also no reason to keep the stack frames for such functions. This is exactly what happens in a proper implementation of tail recursion, the current stack frame is overwritten by the next frame. This allows for (if you desired) infinite recursion, or at least deep recursion, without the worry of a stack overflow. read more