It's better to have unique salts for each user/password hash instead of reusing a limited set of 100 salts.
The reason is because of the way hackers attempt to compromise a database full of passwords once they get a hold of it, in particular using rainbow tables to find known values shared between multiple users.
For example (pseudo-code):
This is bad because once a hacker cracks the first password hash, both users are compromised.
//BAD WAY
var nonUniqueSalt = "some salt value";
var userPass1 = "P@ssword!";
var userPass2 = "P@ssword!";
//Bad! This will be true!
var isSame = (DoHash(userPass1 + nonUniqueSalt) == DoHash(userPass2 + nonUniqueSalt));
This way is better, because the salts are different even if the passwords are the same, so the hacker can't use rainbow tables and is forced to compromise each user's password individually.
//BETTER WAY
var uniqueSalt1 = "unique salt 1";
var userPass1 = "P@ssword!";
var uniqueSalt2 = "unique salt 2";
var userPass2 = "P@ssword!";
//Better! This will be false.
var isSame = (DoHash(userPass1 + uniqueSalt1) == DoHash(userPass2 + uniqueSalt2));
As far as the salting "algorithm" some users mentioned in comments, you don't REALLY need to worry about it too much aside from trying to make the salt unique to each user (because of the reasons described above).
In practice, whatever salt you use will need to be stored in the DB alongside the password hash, so once a hacker has the database, he'll have the value you used for a salt no matter how you go about deriving it.
As such, using a salt based on something like Guid.NewGuid().ToString() is sufficient for simply having unique values for each login.