You'd have to compile the CLR itself into wasm first, which I'm guessing wouldn't necessarily run that well. Language runtimes often provide stuff like os-independent threading or green threads, which have to be implemented all over again for wasm's threading model (I'm not sure it even exists yet). Some CLR features would be redundant, like the security model or the profiling API... and then you'd need to compile your C#/VB/F# down to managed CLR code without using the .NET Framework at all, since so much of .NET depends on having stuff wasm can't provide (not even .NET Core has few enough features to run on wasm). Either you make '.NET Core Core Web Edition Preview 3' and make library developers explicitly target this new framework subset so you can use it, or you just give up and recognise that without most of .NET it's not that worthwhile having C# in the browser.

The difficulties for language developers are on two fronts really. #1 is producing WASM in a compiler backend, instead of LLVM IR / Java bytecode / bare machine code. #2 is getting the language small enough to be possible and not wasteful to implement in wasm. You don't have a filesystem, or really anything a regular OS provides, so you have to be able to strip those language / stdlib features away.

Rust is often cited as a go-to because it can already do #2 easily: #![no_std] strips out the os-dependendent standard library and essentially all of the already tiny stack-unwinding 'runtime'. #1 can be done with an LLVM backend, though it's still a bit of a hack and Rust would prefer to skip LLVM and that whole redundant optimisation phase entirely.

Most importantly, CLR and .NET are just too heavyweight for anyone to bother writing any wasm code in. What are the uses for wasm as it stands? There's basically no DOM interaction yet, so just really fast optimised code that has no OS interaction for crypto and other CPU-heavy tasks. You can't write a game targeting wasm, but you could outsource your ray-tracer there. Plain C++ and Rust are good at that. CLR/.NET is pretty quick when JITing x86 but wouldn't be worth the tremendous effort to port to wasm when you already have C++ and Rust, and they'd still be quicker in the end anyway.

Lastly there's the question of how to run a JIT at all within wasm. I don't think there is a way of creating executable memory regions (ie x86) within wasm, because wasm is independent of who's running it. You would have to instead generate executable wasm regions, which would need to be parsed again... all of which sounds fairly impossible too, as far as I know.