Anthony Steele's Blog : dotNet

Adding OpenId to Oxite, Part 2

Anthony.Steele — Tue, 23 Dec 2008 12:48:00 GMT

The main part of the Openid support is in the controllers and in the view. Fortunately the heavy lifting has been done already, with a library called DotNetOpenId and sample code that started life in Rob Connery's storefront sample, and was worked on by my colleagues Howard Van Rooijen and Pete Worthington before I got hold of it.

First, install the DotNetOpenId library and reference it from the Oxite.MVC project

Add an action called OpenIdSignIn to AccountController:

public ActionResult OpenIdSignIn()

{

var openid = new OpenIdRelyingParty();

if (openid.Response == null)

{

string claimedUrl = Request["openid.claimed_id"];

// Stage 2: user submitting Identifier

Identifier id;

if (Identifier.TryParse(claimedUrl, out id))

{

IAuthenticationRequest request = openid.CreateRequest(claimedUrl);

// email and display name would be nice, but we can do without it

ClaimsRequest claimsRequest = new ClaimsRequest

{

Email = DemandLevel.Request,

Nickname = DemandLevel.Request

};

request.AddExtension(claimsRequest);

request.RedirectToProvider();

}

else

{

ModelState.AddModelError("_FORM", "Invalid identifier");

return View("SignIn");

}

else

{

// Stage 3: OpenID Provider sending assertion response

switch (openid.Response.Status)

{

case AuthenticationStatus.Authenticated:

{

ClaimsResponse claimsResponse = openid.Response.GetExtension<ClaimsResponse>();

string nickname;

string email;

// did we get a claims response?

if (claimsResponse == null)

{

nickname = openid.Response.ClaimedIdentifier.ToString();

email = string.Empty;

}

else

{

nickname = claimsResponse.Nickname;

email = claimsResponse.Email;

}

LogOpenIdLogin(openid.Response.ClaimedIdentifier, nickname, email);

return RedirectToRoute("Home");

}

case AuthenticationStatus.Canceled:

ModelState.AddModelError("_FORM", "Canceled at provider");

return View("SignIn");

case AuthenticationStatus.Failed:

ModelState.AddModelError("_FORM", openid.Response.Exception.Message);

return View("SignIn");

}

return new EmptyResult();

}

private void LogOpenIdLogin(Identifier claimedIdentifier, string nickname, string email)

{

// if the user record does not exist, create it

string userName = claimedIdentifier.ToString();

IUser user = MembershipRepository.GetUser(userName);

if (user == null)

{

Guid defaultLanguageID = LanguageRepository.GetLanguage(Config.Site.LanguageDefault).ID;

MembershipRepository.AddOpenIdUser(userName, nickname, email, defaultLanguageID);

}

FormsAuth.SetAuthCookie(userName, false);

}

And in the SignIn.aspx view add a form for the OpenId to be entered:

<form method="post" action="<% =Url.Action("OpenIdSignIn") %>" class="login">

idselector_input_id = "openid.claimed_id";

</script>

<input type="submit" value="<%= Localize("Login") %>" class="submit button" />

<br />

</form>

Open ID is an identity system that allows you to sign in to websites with a single account.

Your username and password are secure with Open ID - and you don't have to remember yet another password.

</div>

And that's all.

We are using a nice bit of Javascript Ui from IdSelector.com which, as you can see, has a serial number in it. Unfortunately they've stopped issuing these. I hope a good replacement comes along.

There’s lots more that can be done with OpenId here. For instance, the OpenId login form would be useful on the comments page - OpenId users are more likely to be just casual commenters, whereas the people writing the blog could take the time to make a local login. The users created via OpenId do not have any permissions, so they can add comments but not post; which is a sensible default.

I have more than one OpenId, so it would be nice to group them together into my account. Oxite is not yet an OpenId provider, which would be interesting.

A mature system would be able to block open ids based on patterns in the url, allowing or disallowing providers based on security considerations. But Oxite first should gain ability to list users, and change their permissions – e.g. admin, editor, contributor or locked out, and track the user's time and IP of the last login, etc

I’m sure that I made mistakes in this implementation – there’s lots that I don’t know about MVC and about OpenId.

Adding OpenId to Oxite, part 1

Anthony.Steele — Mon, 22 Dec 2008 15:05:00 GMT

I am following up on my last post on Oxite by showing how to add OpenId login support to it. I won't finish this today. This first one will cover the repository changes needed.

First, download the Oxite source and set up the database. From a database perspective, the table where user logins are stored is called oxite_user. In code this is referenced via the IUser interface.

In general, I would like to use the OpenId "claimed identifier" as the user name. User names have to be unique, so this the user name “http://AnthonySteele.myopenid.com/” is used up by my OpenID login, but I think we can live with that. We can tell OpenId logins from regular ones by eye (OpenId logins look like Urls), but I'd like a flag to do it unambiguously.

In the code this flag is an enumeration:

namespace Oxite.Data

{

/// <summary>

/// How does the user log in

/// </summary>

public enum UserLoginMethod: byte

{

/// <summary>

/// Default/unknown value

/// </summary>

Unknown = 0,

/// <summary>

/// The user has a local user name and password

/// </summary>

LocalLogin = 1,

/// <summary>

/// The user logs in using an openId from a different site

/// </summary>

OpenId = 2

}

There could be Cardspace or some other kind of login later. the flag needs to be stored on the user data in the database, with all existing logins marked as “local login”. In SQL, execute:

alter table oxite_user

add UserLoginMethod tinyint not null default 1;

Add the login method to the IUser interface:

public interface IUser

{

... as before...

UserLoginMethod LoginMethod { get; set; }

Then fix the fake implementation of IUser with an auto property:

public class FakeUser : IUser

{

#region IUser Members

... as before...

public UserLoginMethod LoginMethod { get; set; }

Then do some drag and drop to regenerate the LINQ data classes, which will give the database-backed User class a property UserLoginMethod, of type short. Now we want the strongly-typed wrapper:

partial class oxite_User : IUser

{

#region IUser Members

... as before ...

public UserLoginMethod LoginMethod

{

get

{

return (UserLoginMethod)UserLoginMethod;

}

set

{

UserLoginMethod = (byte)value;

}

The Oxite membership repository does not yet have a way to add users, so we need to add one:

public interface IMembershipRepository

{

... as before ...

/// <summary>

/// Add a new user with an OpenId login

/// </summary>

/// <param name="userName">The claimed identifier</param>

/// <param name="displayName">the name to use onscreen</param>

/// <param name="email"></param>

/// <param name="defaultLanguageId"></param>

/// <returns></returns>

IUser AddOpenIdUser(string userName, string displayName, string email, Guid defaultLanguageId);

This is implemented in the fake repository as follows:

public IUser AddOpenIdUser(string userName, string displayName, string email, Guid defaultLanguageId)

{

FakeUser newUser = new FakeUser();

newUser.ID = Guid.NewGuid();

newUser.Username = userName;

newUser.DisplayName = displayName;

newUser.Email = email;

newUser.LoginMethod = UserLoginMethod.OpenId;

Users.Add(newUser);

return newUser;

}

And in the Linq to SQL repository as follows. This isn't perfect (particularly the choice of salt should be unique to the user, and it's not clear how the email should be hashed), but it will do until more complete user-adding code is in place in Oxite.

public IUser AddOpenIdUser(string userName, string displayName, string email, Guid defaultLanguageId)

{

oxite_User newUser = new oxite_User();

newUser.ID = Guid.NewGuid();

newUser.Username = userName;

newUser.DisplayName = displayName;

newUser.Email = email;

newUser.PasswordSalt = "NaCl";

newUser.Password = saltAndHash(userName, newUser.PasswordSalt);

newUser.HashedEmail = saltAndHash(email, newUser.PasswordSalt);

newUser.LoginMethod = UserLoginMethod.OpenId;

newUser.DefaultLanguageID = defaultLanguageId;

newUser.Status = 1;

dataContext.oxite_Users.InsertOnSubmit(newUser);

dataContext.SubmitChanges();

return newUser;

}

So that’s the repositories and domain objects. Next: the controller and view code to make OpenId logins possible.

The ASP.NET MVC beta is out

Anthony.Steele — Fri, 17 Oct 2008 19:55:00 GMT

The ASP.NET Model-View-Controller kit has finally gone into beta. Blog posts from Scott Guthrie, Scott Hanselman and Phil Haack give more details.

The five preview releases that have preceded it were well received, and the Beta finally brings this exploratory and community design feedback phase to a close, so that there should be few changes between the beta and the final release. Scott Guthrie summarised the project's progress as "not 100% feature complete, we think the major subsystems are all getting really close to being done, and that the quality level is now pretty good".

The MVC kit is an interesting addition to the ASP.NET framework, and is a good alternative to the ASP.NET Webforms.

But the big question is, is it ready? Can you develop a site against this beta?

Yes, it comes with a go-live licence.

But should you?

I think so. www.stackoverflow.com is live and facing the internet right now, and is built on it. Jeffrey Palermo is doing "several enterprise client applications" on it.

If you like TDD, simple URLs, and the web way of working rather than ASP.NET WebForms' stateful model, URL routing and other Ruby on Rails-inspired goodness, then the advantages of the MVC kit should outweigh the remaining bugs.

It's going to be an important part of ASP.NET 4.0, so it's well worth getting to know. It's the first Microsoft download to come with jQuery. and apparently, chicks dig it.

Resharper and Source Analysis, not playing together

Anthony.Steele — Wed, 18 Jun 2008 12:34:00 GMT

I've had Microsoft Source Analysis (AKA StyleCop) installed for a couple of weeks. Yesterday I have very belatedly taken the plunge into Resharper.

I have gotten used to the style promoted by Source Analysis. I've gotten into the zone of feeling that warm fuzzy glow from code having no warnings. Howard van Rooijen calls this something akin to OCD and he may be right.

As an aside, if you're coding in C#, I feel that you should get used to the coding style that this tool promotes. It's the most authoritative standard layout that there is, and will most likely be widely used. It's the style that has the backing of Microsoft, and has tools for checking adherence. Other styles don't have those advantages.

All I've done with it so far with Resharper is similar OCD-type things, clicking on what it flags up and deciding to suppress or fix the message for a similar warm-fuzzy feeling when the code is clean again.

There were reasons why I didn't install Resharper sooner - resharper 4.0 has just recently come out of beta, and now we have licences on request. So far, Resharper has been excellent and you should try it at your convenience.

Unfortunately, the two tools don't play well together on all machines, and my laptop is affected. When I edit project properties I now get an obscure error: "COM object that has been separated from its underlying RCW cannot be used."

This error is mentioned here and here.

I now have to say goodbye to one of these tools until this situation is resolved. From this laptop, Source Analysis has gone on holiday. Hopefully it will come back soon, feeling refreshed and ready to help me out. Resharper and I are waiting.

Duplicate Finder

Anthony.Steele — Sat, 23 Feb 2008 15:39:00 GMT

A while ago (June last year) I wrote a utility to detect runs of duplicate lines in files, which is useful for looking for repetitive code that should be refactored. Then I stopped work on it, since it was done. The original blog post is here and the project is up on CodePlex here.

This year I have revisited it with two new features which I think make it much more usable.

The first feature is an MSBuild Task wrapper to compliment the command line interface. This means that instead of using a command line like:

DuplicateFinder -r -t8 -eAssemblyInfo *.cs

You can now also use an equivalent MSBuild Script:

<Project DefaultTargets="RunTest"
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<UsingTask TaskName="DuplicateFinder"
AssemblyFile="$(MSBuildExtensionsPath)\DuplicateFinder.Tasks.dll" />

<ItemGroup>
    <TestFiles
   Include="..\..\**\*.cs"
   Exclude="..\..\**\AssemblyInfo.cs"
/>
</ItemGroup>

<Target Name="RunTest">
    <DuplicateFinder Files="@(TestFiles)"
        DuplicateThreshold="8"
  />
</Target>
</Project>

This may be more verbose, but it has the advantage that you can run it as part of your automated build process. In case you don't always look at the build output, you can use the CountThresholdForError and LengthThresholdForError options to the MSBuild task to fail the build if the duplicates in the source are too numerous or too long.

The second new feature is to cut down or eliminate the false positives. Whole files can already be excluded, but we also need to exclude duplicates where the first line starts with a particular prefix. I'll show you the reason for this.

If we run the duplicate finder on its own source code (excluding the generated AssemblyInfo.cs files, which we know will all look much the same), we get the following:

> DupFinder.exe -r -t7 -eAssemblyInfo.cs *.cs

Processing in C:\Temp\DuplicateFinder\DuplicateFinderLib
6 files read
Duplicate of length 7 at:
Line 1-7 in C:\Temp\DuplicateFinder\DuplicateFinderLib\DuplicateEventArgs.cs
Line 1-7 in C:\Temp\DuplicateFinder\DuplicateFinderLib\LineItem.cs
Line 1-7 in C:\Temp\DuplicateFinder\DuplicateFinderLib\LineItemList.cs
1 duplicate found

The duplicate, line 1-7 of three different files, consists of these lines:

using System;
using System.Collections.Generic;
using System.Text;

namespace DuplicateFinderLib
{
/// <summary>

While these lines may be the same, I don't regard them as "bad" or "cut and paste" code. So I exclude duplicates where the first line starts with "using". Like so:

DupFinder.exe -r -t7 -eAssemblyInfo.cs -xusing *.cs
Processing in C:\Temp\DuplicateFinder\DuplicateFinderLib
6 files read
0 duplicates found

You can also do this in the MSBuild file. More than one prefix can be excluded.

IDesign C# Coding standards

Anthony.Steele — Fri, 12 Oct 2007 15:35:00 GMT

De gustibus non est disputandum.

- A Latin proverb, roughly "don't argue about matters of taste"

As Scott Guthrie noted here:, Juval Lowry has published his C# code layout standards here: IDesign C# Coding standards This compliments the classic: www.tiobe.com/www.tiobe.com/www.tiobe.com/standards/gemrcsharpcs.pdf

Low-level Code standards are wonderful things for your emotions– you can agree fervently with 90% of one, and recoil in disgust at the last 10%.

I'm going through Juval Lowry's document, and comment on the bits that I disagree with or want to explicate, and try to give reasons why I disagree. I'll try to be mindful that arguing that "It looks bad to me" is not a valid reason – what looks right to you is just what you're used to.

Point 9a: "avoid single character variable names" as noted somewhere in Code Complete, the comprehensibility of a short variable name is dependant on how wide its scope is. If the variable is referenced throughout the application, give it a long descriptive name. If it is used only over 2-3 lines of private code, a short or general name will suffice, and anyone can read a variable called "i" over this scope.. However, "loopIndex" is a short enough, general enough name for me to write.

Point 11: use capital letters for types. I find class MyDictionary<Key, Value> more readable than class MyDictionary<K, V> , and it's more in keeping with point 9.

Point 14: Put using statments outside the namespace. Howard van Rooijen pointed out to me that putting the "using" inside the namespace means that it applies to the end of the namespace, not the end of the file, and this is generally what you intend, so there is a case to be made that the "using" goes inside the namespace. I'm not entirely convinced: if this distinction is meaningful to you because you have multiple namespaces in the file, one after the other, then you're doing it wrong. Very wrong.

Point 20: Preface private members with "m_". Is this looking Hungarian? Maybe, but it may be better than the alternatives. Various other conventions on this are in use. Starting with an underscore is not CLS compliant in cases where the var becomes protected and could be called from VB.NET code. I dislike using no prefix at all, just lower case, since it ends up in constructors like this:

class Foo

{

private int bar;

public Foo(int bar)

{

this.bar = bar;

}

Which is just an accident waiting to happen in the constructor – two identically named variables are in scope, and the use of "this." To distinguish between them is not optional.

Point 24: Open curly braces on new line: There is an exception for the simplest of properties,

I.e.

public int foo

{

get { return m_foo; }

set { m_foo = value; }

}

More complex properties should not do this.

Point 25-26 -27

Now we are getting into real matters of taste. See the way that the code on trailing lines lines up with the right-hand of the equals stuff? I don't like that. I prefer to always indent trailing lines by one indentation stop (typically four spaces).

E.g. Not

int someReturnValue = CallAFunction(param1, param2,

param3, param4);

But

int someReturnValue = CallAFunction(param1, param2,

param3, param4);

Despite taste, there are advantages of this layout:

Indentation of the trailing line is consistent with other indented lines.

Indentation does not depend of the contents of the line above.

Indentation does not need to change if the line above changes, e.g. renaming the var.

Indentation is less, and thus there is more room on the line – the code is more readable as it's not all squashed up on the right.

Section 2

Point 12-13 Bill Wagner explained the difference between readonly and const – (Effective C#, Bill Wagner, Item 2) – essentially const is folded in at compile-time, readonly values can be updated by updating the assembly that contains it.

Point 26 Avoid explicit values for enums. Why not give values to enums? I would, when they have to be explicitly the same as ints stored on a database. Also if you don't specify values, the first one will be zero. Zero is best reserved for an "unknown"/"not set" value. (Bill Wagner - item 8). By saying "except when they are integer powers of 2" does not encourage the reader to be mindful that enums in C# (and C) play two slightly different roles - select one from a named, restricted set of values, and to provide a set of flags over those values (this is when the numbers must correspond to the powers of 2).

Point 55 – Why prefer String.Empty over ""? I had to find out why this one is correct. Because it doesn't create a new string instance each time. Apparently it's a trivial difference, but a difference nonetheless.

http://blogs.msdn.com/brada/archive/2003/04/22/49997.aspx

Point 56 – When is StringBuilder faster than concatenation? If there's a loop over lots of strings it is faster, but not if just concatenating three or four strings.

http://www.heikniemi.net/hc/archives/000124.html

http://www.chinhdo.com/chinh/blog/20070224/stringbuilder-is-not-always-faster/

http://www.chinhdo.com/chinh/blog/20070929/stringbuilder-part-2/

ASP.NET state for beginners

Anthony.Steele — Mon, 02 Apr 2007 21:32:00 GMT

Here's a brief example, suitable for beginners, of the differences between windows forms and ASP.NET. In short, the windows forms has real state while running, while ASP.NET has a convincing illusion of it on pages.

We have a simple page, a form containing a label:

</head>

<body>

<div>

<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>

</div>

</form>

</body>

</html>

The code behind the form creates a button at runtime:

public partial class _Default : System.Web.UI.Page

{

protected void Page_Load(object sender, EventArgs e)

{

Button button1 = new Button();

button1.ID = "Button1";

button1.Text = "Click me";

button1.Click += new EventHandler(Button1_Click);

Form.Controls.Add(button1);

}

protected void Button1_Click(object sender, EventArgs e)

{

Label1.Text = "The button was clicked at " + DateTime.Now.ToString();

}

The page shows with a button on it, and when the button is clicked, a postback occurs, then the page on the server executes the button click handler, and the text on the label reads:

The button was clicked at 02/04/2007 22:21:40

Here's a modified version:

protected void Page_Load(object sender, EventArgs e)

{

Button button1 = new Button();

Random rands = new Random();

button1.ID = "Button" + rands.Next(10000).ToString();

button1.Text = "Click me";

button1.Click += new EventHandler(Button1_Click);

Form.Controls.Add(button1);

}

This is the same except the button has a randomised name. Clicking the button on this form has no effect, unless you get extremely lucky with random numbers and get the same value twice in a row.

There are lots of ways to avoid making this kind of mistake, but it underscores the point: The page that gets the postback is not the same page that serviced the original request, it is a new instance. In this case, it has a different button on it. And if the control data coming back to it is not found on the page, that control's event request will be discarded.

If you know what you're dealing with, you can make it work for you.

Delay when starting up a web service

Anthony.Steele — Wed, 07 Feb 2007 12:45:00 GMT

This post is all about a technical issue, an obscure delay when starting up a web service. It's going to be technical, and it's the kind of technical information that's not of great interest until you have puzzled over the same issue, in which case it's extremely valuable. I'll try to keep it interesting anyway. As with most obscure issues, it's caused by the unexpected interaction of several features.

I can't claim credit for working out what was going on – that was done by some dedicated people on the client site, but here is the whole setup:

We had made a web service in ASP.Net 2.0 for the client. The web service made use of a third-party component to generate images. This component was a library that was available from various different environments, including .Net. Technically it was a .net wrapper library for a COM dll. The COM dll was digitally signed, as was the .Net wrapper. Remember that point, it will be important later on.

On the client site they found that once it was installed on the testing server, the first call to the web service took over 30 seconds. This was long enough to cause other parts of the system to time out and fail. The cause was not obvious, since the same code would return in 2-3 seconds on the first call on a lowly development laptop, and tracing revealed that the delay was not in the code that we had written, it was in service start up.

More sleuthing exposed something even more worrying – during start up, some code was trying to contact a remote server and send data onto the network. We certainly didn't require the code to do that. The idea of spyware crossed our minds.

It turns out that the cause of all this is an interaction that is known, but not well documented.

When a digitally signed COM DLL is loaded into IIS, it is given higher trust than an unsigned one. Part of the design of digital signing is "certificate revocation", whereby if a signed binary is found to be up to no good, it can be added to a worldwide "Certificate Revocation list". This blacklist is stored on the signing authority's server. When the signed binary is loaded, the host will contact this server and see if the binary's signature is still valid. If so, the success is recorded so that the blacklist server is not contacted again for that binary, at least until a timeout period of several days expires and another check is done to see if the binary has been blacklisted in the meantime.

"A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." – Leslie Lamport

But there is a third possibility: what if the blacklist server cannot be contacted? The server could be down, the network between client and server could be out of action or the client might not be on a network at all. It is not acceptable for a signed binary to stop working altogether simply because a remote server is down, but it is also not OK for a blacklist to be circumvented by unplugging your own network cable. So in this case, the binary is loaded as if it was not signed, and no success is recorded. Another attempt will be made to contact the blacklist server the next time the binary is loaded into memory.

In our case, the testing server where out web service was being installed was behind a comprehensive firewall that did not permit the code to connect to arbitrary web servers – and we didn't need that functionality, or so it seemed. So each time the third-party com DLL was loaded, The API function WinVerifyTrust was called twice, and the whole process spent thirty seconds waiting for the network connection to time out: each call had three retries each with a five-second timeout. There doesn’t seem to be any way to configure the count or timeout of WinVerifyTrust.

The attempted network connections that we were worried about turned out to be to crl.verisign.com and crl.thawte.com

The solution

There are three possible ways to extract yourself from this situation, should you find yourself in it:

1) Open up the server's firewall enough to let the blacklist server query succeed. In our case, this wasn't going to be an easy option since we had no direct control over the administration of the testing and production servers.

2) Turn off certificate revocation checking for the whole server (links below). I haven't tried this, but it looks like it might work. This is, however, a drastic step that might compromise the security of the server. We didn't do this since it wasn't our server to configure. It wasn't just one server either.

3) Get versions of the binary files that are not digitally signed. Fortunately the vendor was by this time as pleased to find out what was going on as we were, and happily supplied us with these files. It seems odd that disabling the security features is necessary to get it to run, but there it is.

Links: A discussion of the same issue with a different vendor's control:

http://blogs.xceedsoft.com/plantem/PermaLink,guid,3dde0262-1b7f-45d3-9a6e-164c842e422d.aspx

How to turn off certificate revocation checking:

http://digital.ni.com/public.nsf/allkb/18e25101f0839c6286256f960061b282

http://forums.ni.com/ni/board/message?board.id=232&message.id=827&page=3

WinVerifyTrust API function: http://msdn2.microsoft.com/en-us/library/aa388208.aspx

Microsoft AJAX and videos

Anthony.Steele — Tue, 30 Jan 2007 12:32:00 GMT

First, the Microsoft AJAX toolkit for ASP.NET 2.0 has recently been released as version 1.0.

You can see live demos of the controls by pointing your browser over here. it looks good in firefox, which is good.

I've been watching the MS Ajax videos (or screen-casts if you like) on my laptop while on the train. They are presented by Joe Stagner. I've now watched almost all of them. They're based on the beta version of the MS AJAX toolkit, but I don't think it has changed much in the release.

While these videos are very useful, after a while I noticed a few elements of them that could easily be improved.

Firstly, the large number of spelling mistakes on Joe's web page shown on the screen at the start, e.g. the word "yesterda" in a heading. I thought everyone had a spelling checker these days.

Secondly, taking a minute in each and every video to talk briefly (and incompletely) about how if you don't have this tab of AJAX controls in the Visual studio toolbox, you need to install the dll which comes in a zip file…. It's really tiresome when you're hearing that for the 20th time. Just say "if you don't have this, see my getting started video for instructions on how to set it up". That's all. Explain it well once, and then don't explain it badly twenty times.

Thirdly, each video is basically to demonstrate how to use a particular control or feature. We spend seven and a half minutes out of eight looking at markup, and the last half a minute looking at the results. I think it would be more interesting and would give a better understanding of where we were going if the video could be started with a look at the finished product, then show how it was done.

Update: on 13 Feb 2007, Joe Stagner's videos were updated for version 1.0 of the AJAX toolkit. See http://www.asp.net/learn/videos/

Generic lists

Anthony.Steele — Wed, 15 Nov 2006 12:49:00 GMT

I have spent a fair amount of time in the past writing business objects, and as soon as we'd made a "Widget" class we needed a "WidgetList" class. I got pretty practiced at throwing these lists out quickly since they were all the same. Depending on the particular project's design decision, we'd encapsulate or inherit from a weakly-typed list.

A large number of innovations in computer programming are finding new ways to adhere to the ideal of DRY: Don't Repeat Yourself. So now with generics, all you need is "List<Widget> myList = new List<Widget>();"

The problem is that these lists weren't actually all the same. They did all had Add() and Clear() methods, Count and Items[] properties, and so on. But the item class was created because it wasn't just like anything else existing, and this carried over to the list. For instance, if it was a list of integers you wanted the Sum, Min, Max and Mean of the contents. If it was an address list, there'd be a method to find the primary billing address in a list of addresses for a client, and so on. Good object-oriented style says that those methods should be attached to the object where they do their work, i.e. on the list.

There are ways to do this in generics. Here’s a generic subclass of a generic list:

public class MyList<T> : List<T>

{

…

}

And a specific subclass of a generic list:

public class IntList : List<int>

{

// sum all the ints in the list

int Sum()

{

int result = 0;

foreach (int item in this)

result += item;

return result;

}

The only drawbacks to this technique that I know of are that the attributes that are attached to List<T> are not automatically attached to its subclasses. List<T> is marked [Serializable], but MyList<T> isn’t, unless you do so manually. It’s easy to forget that it’s not a complete drop-in-replacement unless you add the same attributes as the base class. John Rayner has noted similar issues.

Here’s a more complex example, using both generic and specific subclasses:

public class BusinessObject

{

.. virtual methods for all business objects

}

public class BusinessObjectList<T>: List<T>

where T: BusinessObject

{

… methods on lists of business objects

}

public class Widget: BusinessObject

{

…

}

public class WidgetList: BusinessObjectList<Widget>

{
.. a list of widgets, with businessObject-specific and widget-specific methods

}

And finally an odd one, a class that participates in its own base class:

public class GenericBase<T>

{

.. protected methods on T

}

public class Widget2 : GenericBase<Widget2>

{

}

Which means that Widget2 has access to all the inherited generic methods, in form strongly typed for its own use. I have not yet worked out if using this technique is a good idea or not. I got this example from a book that I was looking through; but the title escapes me now.