Develop Reference

Is it OK to use dictionaries when I don't need to quickly access their values?

Normally, I use a dictionary like a list, but with a key of a different type. I like the ability to quickly access individual items in the dictionary without having to loop through it until I find the item with the right property (because the property I'm looking for is in the Key).
But there is another possible use of a dictionary. I could just use the Key to store property A and the Value to store property B without ever using the dictionary's special functionality. For example, I could store a list of persons just by storing the forename in the key and the family name in the value (let's assume, for the sake of simplicity, that there won't ever be two people with the same forename, because I just couldn't come up with an better example). I would only use that dictionary to loop through it in a foreach loop and add items to it (no removing, sorting or accessing individual items). There would actually be no difference to using a List<KeyValuePair<string, string>> from using a Dictionary<string, string> (at least not in the example that I gave - I know that I could e. g. store multiple items wiht the same key in the list).
So, to sum it up, what should I do when I don't need to use the special functionalities a dictionary provides and just use it to store something that has exactly two properties:
use a Dictionary<,>
use a List<KeyValuePair<,>
use a List<MyType> with MyType being a custom class that contains the two properties and a constructor.

Don't use dictionaries for that.
If you don't want to create a class for this purpose, use something like List<Tuple<T1,T2>>. But keep in mind a custom class will be both more readable and more flexible.
Here's the reason: it will be much more easy to read your code if you use proper data structures. Using a dictionary will only confuse the reader, and you'll have problems the day a duplicate key shows up.
If someone reads your code and sees a Dictionary being used, he will assume you really mean to use a map-like structure. Your code should be clear and your intent should be obvious when reading it.

If you're concerned with performance you should probably store the data in a List. A Dictionary has lots of internal overhead. Both memory as well as CPU.
If you're just concerned with readability, chose the data structure that best captures your intent. If you are storing key-value pairs (for example, custom fields in a bug tracker issue) then use a Dictionary. If you are just storing items without them having some kind of logical key, use a List.
It takes little work to create a custom class to use as an item in a List. Using a Dictionary just because it gives you a Key property for each item is a misuse of that data structure. It is easy to create a custom class that also has a Key property.

Use List<MyType> where MyType includes all the values.
The problem with the dictionary approach is that it's not flexible. If you later decide to add middle names, you'll need to redesign your whole data structure, rather than just adding another field to MyType.

Iterating over Dictionary with foreach, in what order is this done?

Say I have a Dictionary, and I add each key and value entry in a specific order.
Now, if I want later to be able to iterate this Dictionary in the same order entries were added, is it the order I get with simple foreach loop on this dictionary?
If not, I will be glad to hear how can I do that, I know this can be done easily with List instead of Dictionary but I don't want to.
Thanks

Normal Dictionary does not guarantee order of items.
You need OrderedDictionary if you want to maintain order items where added to it. Note that there is no generic version of this class in .Net framework, so either have to give up some type-safety or find other implementation (i.e. https://www.codeproject.com/Articles/18615/OrderedDictionary-T-A-generic-implementation-of-IO as suggested by Tim S).
Alternatively if O(log n) lookup is fine and keys should be sorted - SortedDictionary.

Sounds like what you want is a Queue<T>: http://msdn.microsoft.com/en-us/library/7977ey2c.aspx
Add your KeyValuePair<T, U> items to it in the order you want and then foreaching over it will be in first-in/first-out order.

Dictionarys are hash tables, which means that you can't guarantee that iterating the pairs will return them in the same order you added them.
Each pair is a KeyValuePair<T_K, T_V>, so you could have a List<KeyValuePair<string, string>> that would let you iterate in the order you add them if that's what you need.

The internal sort of the dictionary will depend on the hash function used. However if you need a sorted view of the data, you can use Enumerable.OrderBy.

Best way for constructing a unique list of objects in C#

I'm wondering whether it will be quicker to follow one pattern or another for constructing a unique list of objects in C#:
Option 1
Add all the items into a generic list
Call the list.Distinct function on it
Option 2
Iterate over each item
Check whether the item already exists in the list and if not add it

You can use HashSet<T>:
The HashSet class provides high-performance set operations. A set
is a collection that contains no duplicate elements, and whose
elements are in no particular order.
You can provide custom IEqualityComparer<T> via constructor.

This is one of those "should I use a shoe or a brick to pound a nail into the wood" questions. You should use the appropriate data structure for the job, which based on your requirement of "constructing a unique list of objects", the HashSet<T> class satisfies.
If you require the items in list format, you can always call ToList() on the set.

If you are concerned about the performance of looking up unique items, use a Dictionary<TKey, TVale>. Also, a dictionary requires unique keys, so you will never have duplicates.

How to insert a key/value pair into a dictionary?

When I add an entry to a Dictionary using Add, the KeyValuePair is added at the end of it. I would like to preppend it thus when I iterate on KeyValuePair's, it is the first item.
Is there a way to do it with a Dictionary or should I build a List<KeyValuePair<TKey, TValue>> or do you have a better proposition?
EDIT : I thought I could work on the enumeration in Dictionary, it seems I can't.
I tried with List<KeyValuePair<TKey, TValue>> which was not very practical.

The Dictionary class doesn't have a concept of order within it - there is no positional index to the Dictionary.
Take a look at the OrderedDictionary class in the System.Collections.Specialized namespace if you need to use a positional index on a dictionary.

I think you're looking for the OrderedDictionary.

Use OrderedDictionary.
Represents a collection of key/value pairs that are accessible by the key or index. You can insert the key value pait at desired index.

If you are looking to preserve order, Dictionary is not the collection that you want to use (it doesn't have a concept of order).
There is an OrderedDictionary collection that will help if you need to have an indexed dictionary.
There is also a SortedDictionary collection, that will sort the values that you add based on the key value.

Officially, you can never know in what order your key-value pairs will come out of a Dictionary<,> if you iterate through it (foreach it, thereby calling GetEnumerator()). And certainly, if you Remove some items from your dictionary, and later Add some other items, when you foreach your way through the collection, the new items will be in the space of the removed items, not in the end of the iteration "list".
But: If you know you never Delete from your Dictionary<,>, it looks like the enumeration yields the items in the order they were added. There is no guarantee this will always work, but it looks like it works in the current implementation.
So if you dare rely on this, you could just say
foreach (var keyValuePair in myDict.Reverse())
{
...
The Reverse method is part of LINQ (needs using System.Linq).

When to use a HashTable

In C#, I find myself using a List<T>, IList<T> or IEnumerable<T> 99% of the time. Is there a case when it would be better to use a HashTable (or Dictionary<T,T> in 2.0 and above) over these?
Edit:
As pointed out, what someone would like to do with the collection often dictates what one should be using, so when would you use a Hashtable/Dictonary<T,T> over a List<T>?

Maybe not directly related to the OPs question, but there's a useful blog post about which collection structure to use at: SortedSets
Basically, what you want to do with the collection determines what type of collection you should create.
To summarise in more detail:
Use IList if you want to be able to enumerate and / or modify the collection (normally adding at end of list)
Use IEnumeration if you just want to enumerate the collection (don't need to add / remove - usually used as a return type)
Use IDictionary if you want to access elements by a key (adding / removing elements quickly using a key)
Use SortedSet if you want to access a collection in a predefined order (most common usage being to access the collection in order)
Overall, use Dictionary if you want to access / modify items by key in no particular order (preferred over list as that's generally done in order, preferred over enumeration as you can't modify an enumeration, preferred over hashtable as that's not strictly typed, preferred over sortedlist when you don't need keys sorted)

You use a hashtable (dictionary) when you want fast look up access to an item based on a key.
If you are using List, IList or IEnumerable generally this means that you are looping over data (well in the case of IEnumerable it definitely means that), and a hashtable isn't going to net you anything. Now if you were looking up a value in one list and using that to access data in another list, that would a little different. For example:
Find position in list of Item foo.
Position in list for foo corresponds to position in another list which contains Foo_Value.
Access position in seconds list to get Foo_Value.
Here is a link describing the different datatypes.
Another link.

Use a hashtable, when you need to be able to (quickly) look up items by key.
Of course, you can search through an IList or IEnumerable etc for a matching key but that will take O(n) time rather than O(1) for Hashtable or Dictionary.

Hash-tables are good choices if you are often doing "for something in collection" and you aren't concerned about the order of items in the collection.
Hash-tables are indexes. You can maintain a hash-table to index a list, so you can both choice to access it in order or randomly based upon the key.

Hashtable optimizes lookups. It computes a hash of each key you add. It then uses this hash code to look up the element very quickly. It is an older .NET Framework type. It is slower than the generic Dictionary type.

You're not really comparing the same things, when I use a dictionary it's because I want to have a lookup for the data, usually I want to store a list of objects and I want to be able to quickly look them up using a key of some kind.

I use Hashtables quite often to send back key/value collections to Javascript via page methods.
Dictionaries are good for caching things when you need to retrieve an object given its ID but don't want to have to hit the database: Assuming your collection is not large enough to induce a large number of collisions and your data needs retrieving often enough for an IEnumerable to be too slow, Dictionaries can give a decent speed-up.

There's no way of telling exactly without knowing what the collection is for, but unless the items in your collection are unique you cannot use a hashtable, as there will be nothing to use as a key. So perhaps the rule of thumb you are looking for is that if your members are all different and you want to pull individual instances out by key, use a hashtable. If you have a bunch of items that you wish to treat in the same way (such as doing a foreach on the entire set) use a list.