Best way to get 32 bytes from PBKDF2 Use the PBKDF2 output as an HMAC key, hashing two different inputs - once for 20 bytes and once for 12 :

using (var PBKDF2 = new Rfc2898DeriveBytes(passwordBytes, salt, 100000))
{
    HMACSHA1 hmac = new HMACSHA1(PBKDF2.GetBytes(20));
    hmac.Initialize();
    byte[] aesKey = hmac.ComputeHash(new byte[] { 1, 0, 1 })
        .Concat(hmac.ComputeHash(new byte[] { 1, 1, 1 })).Take(12).ToArray();
}


Or perform PBKDF2 twice, splitting the iterations, and using 2 different salts :

byte[] aes2;
using (var PBKDF2 = new Rfc2898DeriveBytes(passwordBytes, salt1, 50000))
    aes2 = PBKDF2.GetBytes(20);
using (var PBKDF2 = new Rfc2898DeriveBytes(passwordBytes, salt2, 50000))
    aes2 = aes2.Concat(PBKDF2.GetBytes(12)).ToArray();




References: Rfc2898DeriveBytes ,  HMACSHA1  .
It would help to understand the context a little.  I'm assuming you're trying to arrive at a password-based key and you're trying to maximize the brute-force time required to guess the key.  But maybe this data will be used as a tag, or you're interested in maximizing the time to create a password-key dictionary or something.

I would consider the search space an attacker would have to go through in making your decision.  The first one has a search space of $|passwordBytes|\times|salt|$.  The second has a search space of $|passwordBytes|\times 2\times|salt|$, so requires $O(2^{|salt|})$ more computation.  Doubling the iteration count just doubles the computation (i.e. adds one bit of complexity).  The time to compute a dictionary would be higher for your second option.

However, it would actually be easier to say something about just the first 20 or just the last 12 bytes in the second scheme (since it uses a lower iteration count), which could allow brute-forcing the other half even more trivially.  To prevent this, you'd do better to follow CodesInChaos's suggestion and cascade operations, but make sure the final output is a single output from a secure primitive.  For instance, you might use $tmp = PBKDF2(passwordBytes, salt1, 50000)$ to get $|passwordBytes|$ of data, then use $SHA256(PBKDF2(tmp, salt2, 50000))$ (or even just $SHA256(tmp || salt2)$) to get 32 bytes.  This makes the search space as big as $|passwordBytes|\times 2\times|salt|$ but doesn't leak information from just one or the other halves of the output.

In any case, depending on how you're using the data, I suspect some other primitive (like SHA-256) might be useful for you.