Roll your own lists & collections in C#

Most days, instead of just using the built in lists when working with collections / lists, I create my own lists which inherit List<T>.

This gives me loads more flexibility to add my own helpers with comparing and retrieving particular items.

public class RowCollection : List<Row>
{
  private int Compare(Row row1, Row row2)
  {
    return row1.GetValue(SortColumn).CompareTo(row2.GetValue(SortColumn));
  }

  public Row Find(int id)
  {
    foreach (Row row in this)
    {
      if (row.Exists(“id”) && row.GetValue(“id”).Equals(id))
        return row;
    }
    return null;
  }

  public void Sort()
  {
    Comparison<Row> rowSort;
    rowSort = new Comparison<Row>(Compare);
    Sort(rowSort);
  }

  public string SortColumn { get; set; }
}

This example is part of a SOLR library I use for displaying results.  ‘Row’ is simply a class for making it easier to parse and traverse the results.

The located assembly’s manifest definition does not match the assembly reference Pt.2

If you are using a solution with many projects that reference the same assembly namespace, check that all the references point to the same assembly.

If they don’t you’ll get the mis-match exception since the solution will build one .dll to the bin, but this may not be the .dll your project requires.

Abstract classes and interfaces

A C# class may only subclass—inherit from—one other class. Therefore, by inheriting from (subclassing) an abstract class, the derived class has used up its ability to participate in a meaningful type hierarchy.

C# supports single inheritance: C# does not support multiple inheritance from multiple classes like C++ does. But, by using abstract classes and interfaces, C# programs can achieve most of the same functionality without the confusion and maintenance problems associated with multiple inheritance.

Interfaces separate the syntax rather than the semantic contract from the implementation. Classes can be designed to decouple the semantic contract from the implementation. For example, abstract classes can be separated in a different assembly than their concrete implementations.

http://en.csharp-online.net/Should_I_use_an_abstract_class_or_an_interface%3F

*.get must declare a body because it is not marked abstract or extern.

Got this the other day working with a third party code-base, seems the body-less property get/setters only arrived in .net v.3+ so double check the project properties for the version the project is running under.

Could not load file or assembly Microsoft.Practices.*

I was having problems with a third party site that were using these assemblies as well as a solution (which referenced these project) I created.

Seems there are differences between the assemblies that appear in the reference dialogue and the ones that actually live in the program files bin directory.

C:\Program Files\Microsoft Enterprise Library 5.0\Bin

This post saved the window from a jumping visitor:

http://blogs.msdn.com/b/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx

Following

  • funniest10k
  • evangotlib
  • the-absolute-funniest-posts
  • mikelernerphotography
  • attentionindustry
  • tastefullyoffensive
  • infoneer-pulse
  • merlin
  • poplipps
  • cavalier
  • redshooter
  • frezned
  • amyvernon
  • minimalistco
  • theclearlydope
  • deviantart
  • yagottabelieve
  • mashable
  • poptech
  • gregbabula
  • john
  • teaim
  • despicablealexis
  • purple-lightsaber
  • toptumbles
  • hellonewyork
  • nonprofit-design
  • plus5mace
  • wantful
  • pixel2html
  • adobegripes
  • kimjongillookingatthings
  • tuneage
  • mikehudack
  • sirmitchell
  • officialbeastieboys
  • wondertonic
  • jordanwaller
  • badassjs
  • iiiil0liiii
  • fuzzythinking
  • manxmidge
  • rosskempfolds
  • londonelek
  • bigpinots
  • hoveringartdirectors