Short story: Ultimately, your question comes down to a question of the quality of the Windows RNG. Your approach is fine if your RNG is good, but you're trusting the largely opaque Windows RNG to give you a perfect 32 bytes of entropy. I would recommend generating more bytes and then using a hash or KDF to compress it to 32 bytes.
Slightly longer story: All good random keys are generated from the same principle: An $n$ bit key is generated from a source providing $m$ bits of output with $n$ bits of entropy. If the source is high quality entropy output, then at best $n = m$ and the direct output can be used as a key. Otherwise, you would use something like a hash or a KDF to compress the $m$ bits of entropy to an $n$ bit key. Pick a good entropy source, and the random bytes it outputs will be a good key.
In your case, you are using the recommended cryptographic RNG provided by your host OS. This seems like a reasonably secure RNG source, but in general we like to be cautious about these things since there are many practical things that can go wrong. Since Microsoft doesn't publish the details, by default we tend to have more skepticism about it. A series of low entropy bytes might be output, the RNG might be badly constructed and a compromise of our key might lead to a compromise of the system's RNG state and thus future or past keys, and other such problems. To mitigate these failures, generally good practice is to pass RNG output through a hash or KDF before turning it into a key (even if $n = m$).
The Windows CryptGenRandom API is another portal into the Windows RNG, and I would think would work very similarly to the .NET call you referenced. Note that it has been at least in part reverse-engineered and had a few attacks against it, although I don't think low entropy itself is one of them.
