Last year I did much performance testing of .NET. Yes, it is fast. Code runs up to 200 times faster than ASP (that's what you get when you compile :) ).
There are issues with building web pages - be sure to use StringBuilder to concatenate strings into a web page or you will actually get slower performance than ASP for large pages.
ADO.NET is faster than ADO for static record sets. For lots of good figures, see "Technology Presentations" tab at www.vi-i.com.
dotnetweblogs.com/jarnold/posts/6279.aspx explains the iEnumerator behavior I observed. See his entry!
Sam Gentile turned me on to this blogging. It is great. Way to get and share continuous lore. Thanks to all of you fellow participants.
Have been chasing down some crashes in aspnet_ws. Seems to occur when an error routine that ends generation of HTML for an ASP.NET web page is called, and then throws another error and calls itself again, etc. But I couldn't simulate the crash with a simple endless recursive call. Will keep you all posted if I can figure out.
.NET Framework Version was 1.1.
Well, here goes for my first blog.
Was working on an ASP.NET app which had ADO (aspx page starts with <%@ Page validateRequest=false ...%> and decided to convert it to ADO.NET. I decided to convert it to ADO.NET without having to fix much in the original code by creating a class that simulated the ADO behavior. In doing so I encountered an interesting "feature" in .NET enumerators.
I wrote a class called Table that allows me to do the following:
Dim oTable As Table
oTable.Open("SELECT * FROM Sales")
Dim nRows As Integer = oTable.nRows
Dim oField As Column
Do While Not oTable.EOF
For Each oField In oTable.Fields
...
Next
oTable.MoveNext
Loop
After creating classes Table and Column, I found that I needed to create a class Columns and have oTable.Fields return an object of type Columns, where Columns implements the IEnumerable interface, and then a class ColumnEnumerator that implements the IEnumerator interface. Then came the surprise that I wish to share:
The iEnumerator interface specifies that ColumnEnumerator must have a Reset and a MoveNext and a Current method. But when the statement
For each oField in oTable.Fields
executes, the Reset method is not called, and the MoveNext method is called once before the first call to Current. So I had to code around this accordingly. This does not seem to be quite the desired design. Anyone else seen this "feature"? Is it documented somewhere?