You can always provide a custom controller factory that will resolve these classes differently. And I do agree that controllers need no Controller type name appending because after all they're just like any other class. Their OOP ancestor type defines them as controllers anyway (IController, Controller...)
Although it may have something to do with Visual Studio. Similar to Attribute classes. Maybe Visual Studio wouldn't provide additional context menu items to classes that don't end with Controller. When being in controller action you can easily navigate (or create) to the matching view.
So say the experts and I do agree. There are other conventions like these in .net framework as well but people don't complain about them.
Think of collections, dictionaries, attributes, lists and other types that also use similar suffixes without particular reason. They'd work either way, but they're much easier recognisable by their users - developers - who instinctively know how they should work and when to use them.
Imagine having a ProductController that likely handles Product application model entity instances. By not having the controller naming convention, we'd have two types with the same name hence would always have to provide namespaces to distinguish between the two. But because we do have this convention this is not necessary and no type clashes occur.
public class ProductController : Controller
public ActionResult Index()
// we'd have to distinguish this Product type here
IEnumerable<Product> result = GetProducts();
I agree that conventions are good and they are present throughout .NET for a reason, but most conventions aren't enforced, I just find it a strange decision to enforce the convention in this case as there is absolutely no need. A dictionary, list etc will be used throughout an application, whereas in 99.9999999% of the times controllers are going to be in the same place.
@dormisher: that is true, but with those 99.9% of times it doesn't hurt to have convention but the rest 0.1% benefits lots by them. So let's have a convention.
@dormisher: Even more important: as Asp.net MVC team says, this convention has been introduced, because you may have a ProductController class that will likely be handling Product application model class. If there was no controller convention, you'd have type name clashes and would always have to provide namespaces to distinguish between the two. By having Controller suffix on controller types, this is not necessary.
also I take your point about the type clashes, that is a good enough reason I think