From what I read here: How to securely hash passwords?, you're supposed to iterate the hashing.
You didn't understand that correctly. The password hashing requires a work factor to add some security to otherwise insecure passwords, as passwords commonly do not contain enough randomness to be be secure.
bcrypt internally uses a block cipher. But it repeats the key setup rather than the block encrypt itself to implement a work factor. Without it you cannot encrypt the bcrypt specific string, so the work needs to be performed before you can compare the password hash. As bcrypt internally doesn't use a (cryptographic) hash at all, it would be kind-of hard to repeat it.
In other words, bcrypt is a password hash, it doesn't use a hash - it uses a block cipher called Blowfish.
Other password hashes (or Password Based Key Derivation Functions) such as PBKDF(1) and PBKDF2 do use a repeated hash, or rather they repeat a hash based MAC (HMAC). scrypt in turn is build upon PBKDF2, so it also depends on hashing.
However in the implementation of BCrypt for .Net uses the workfactor (2^wf iterations) in the 'GenerateSalt' function.
That would be weird. Generating the salt is just getting 16 bytes from a (secure) random number generator. It is the key setup that is repeated, and that also requires the password as input.
It is quite common for developers to mess up their design or method naming, so I'm not saying that you're wrong stating this.
Did I missunderstand the concept of a salt? A random string that you append to the password you want to hash, to make the hash for the same password with different salts different?
You understood the function of the salt just fine. The salt is also used to avoid rainbow table attacks though, so just avoiding the same password to create the same password hash in the normal password hash table or tables is just one function of it.
However, how the salt is used within the password hash depends on the scheme used. For bcrypt the salt is encrypted into the state of the key setup, so it is never put in front of the password. To put it in front of the password would be a good idea if a hash was used internally by bcrypt, but we've already established that that isn't the case.
The salt is just a binary string of 16 random bytes, e.g. from Wikipedia:
salt: array of Bytes (16 bytes)
you're confusing the hash string with the salt itself; the salt is just a 22-character portion of the hash string, with the salt bytes encoded using radix 64, e.g. the Wikipedia example:
^ salt encoding ^^ password hash encoding ^
This encodes the 16 byte salt in a password hash radix 64 encoding. The password hash itself is another radix 64 string simply stuck onto the end of the salt string. The salt is decoded back to bytes during verification; the characters are just a textual representation of the 16 random bytes.
If the random bytes of the salt were directly put into a text file, the file and / or the salt would become corrupted (as control characters such as End-Of-File - EOF - are completely valid for the salt). So the radix 64 encoding is used to represent the bytes as text; this is also called an ASCII armor as it protects the byte values against processes handling the text file.