From this question, the OP posited taking a user's entered password, running it through BCrypt, then running that through SHA256 to produce a 256-bit password-derived key. (EDIT: To clarify, these two options are considered as producing a single key value; the "intermediate" BCrypt hash's sole purpose is to be hashed with SHA-256 and is not used for any other purpose). The obvious alternative is to simply plug HMAC-SHA256 in as the PRNG for the PBKDF2 algorithm shell, with an equivalent number of rounds of derivation.
The question is, what are the relative strengths and weaknesses here? Obviously, both approaches, properly implemented and configured, would present a significant proof of work to an attacker. The BCrypt+SHA256 combination looks a bit more complex, but if you have ready-made implementations of these two and would have to roll your own PBKDF2 implementation (the PBKDF2 built into .NET is hardcoded to use SHA1, not SHA256), the first option would end up simpler. I see one advantage to PBKDF2 when implemented with a 256-bit HMAC; The actual BCrypt hash is only 192 bits, so that, and not 256 bits, is the maximum amount of entropy inherent in the BCrypt+SHA256 combo instead of a true maximum of 256 bits with PBKDF2-SHA256. BCrypt+SHA256 would still be better than the 160-bit Rfc2898DeriveBytes implementation of PBKDF2 in .NET, and even 128 bits, produced by truncating or XOR-folding any of the above hashes, is plenty secure enough with a good AES AEAD mode.