I think this feature has nothing to do with visual studio. VS is only here bound to their system to allow for nice editor features. but compilation/link/relaunch is handled by them.
Surely, it cannot work for everything, you cannot modify core code, it must be within precise "plugin" architecture, and surely, like android, there must be a lot of constraints. You mentioned before something about serialization, this is exactly what android requires of all application because they can be killed at any time.
it is easier to rebuild a game logic that says "when space hit then jump" which requires no data, than rebuild the code of the deferred pipeline because it would require rebinding all uniforms, rebuild all render targets etc etc.
But of course, it is still amazing.

Some great commentary and questions here, here's some responses which I hope clarify things:

@Lightness1024 and Radikalizm:

We're using Visual Studio as our compiler, since that's the most common compiler used for games, and there's a freely available Express version which we also support. Other compilers and OSes could be supported but would require a little extra work. We don't use any specific features of VS for the base implementation, though the pragma comment library feature is an easy way to get libraries added - but we intend to supply a cross platform version eventually. In particular I'll likely port to Mac OS X and Linux at some point, though that may not be for a few months due to other work.

@Hodgman

Myself and the other authors are all professional game developers with console experience, and a similar implementation at Crytek is working on the XBox 360 (see our develop conference slides linked from the blog). Memory is certainly an issue for console development in general and this technique would add some overhead, though there are development consoles with more memory to aid with this.

Many changes could be done with in-place serialization or even serialize to disk/network etc. and back so as to be able to free up memory prior to recreating the objects and thus also handle fragmentation issues. Additionally, though in principal all data types could be runtime changed (for example I've used the technique for graphics coding), most of the larger asset types are likely to have a very stable memory format and so not need runtime serialization.

We may make a client/server style runtime compiler for systems like iOS, Android and consoles at some point, but we'd not be able to open source the console work due to licensing conditions.

Hope this helps, I'll try and monitor this thread and try to answer questions that come up.

thanks for replies.
but all that seems to me a little scary. trying to maintain heap while rebuilding code in a non-managed/non-interpreted language :s
what happens if a plugin creates a bunch of instances of structure S and we change the content of structure S to a new layout of data we will name S2, then after rebuild, if the runtime tries to access those old instances the code will think to see S2 structures but actually those are S structures in memory. This will corrupt the content and crash if it involves pointers.
how would that be handled ?

It's actually a lot easier than you'd think to use, and we have an error handling mechanism to enable you to correct these problems and keep working. Even if the game crashes in a completely fatal way, you're no worse off than if you'd made an error in your code, compiled and ran it as normal. If data gets corrupted, you could re-load a save point (currently our demo doesn't create save points when loading new code, but it would be trivial to add).

Best way to find out if it works for you is to give the demo a try.

Note that our primary target is programmers - who are used to dealing with bugs and crashes and the state they create is code which doesn't get lost when the program crashes. If you want to use this for designers (and we believe it can be, see latest post on the console for one example), further error protection methods such as the above mentioned save points should be used.

If anyone is following this thread still and using OS X, they might like to know we've recently added OS X support (only tested 10.8 and XCode 4 Clang++ so far). Would appreciate any feedback.