Sahil Malik points out that Microsoft has found a way to distribute Virtual Machines for Windows by time bombing them. In fact, they now have quite a number of them available for download.

Sahil has another request, to be able to do the same himself:

Extend that time bomb mechanism, so parties other than Microsoft can play. I should be able to create a solution based on MSFT technologies, and hand over a VHD for the world to play.

That is something that I would like to see very much. My company has a lot of virtualization stuff going on, and I would be very interested in being able to legally distribute a VM that can be use to boot-and-go in various scenarios.

I would like to add another request to that, not only do we need to be able to distribute time bombed VMs, we also need a way to white-list them, if we want to use the VM for more than the allowed period. My company has done several projects where deployment has consisted of xcopy the VM file to the VM server, and the booting.

I spoke about it in the past, here

Here is an idea for a kick-ass Reflector plugin. We already have Reflector plugins for outputting entire projects out, but what I would really like to see is a plugin that takes it one (big) step further and generate the PDB as well.

A PDB file allows Visual Studio to debug, it contains the correlation between the compiled code and the source code, enabling stepping into the code. The important idea here is that Reflector is capable of producing botht he source code and the PDB, which would allow us to debug into assemblies that we don't have the source to.

The big benefit of generating the source and compiling ourselves is that we don't need to do it for the whole chain. The immediate use of this would be to finally see what black magic is making the view state put values in completely random places.

We have assembly redirection for compiled assemblies, but is there such a thing for the compiler?

Spesifically, my problem is replacing a production version of a dll with a modified debug version, and then runing that. The issue is that I can't use the production dll and then replace it for debugging + assembly redirect, since on of th dll has a dependency on that modification.

I solved that issue by recompiling everything against the debug modified version, but that is a PITA. Is there a better way?

The problem right now is that the compiler will complain about mismatch types (can't convert from Foo.Bar to Foo.Bar), because they are of difference assemblyes.

One thing I really wish that I could do is to make the debugger use Reflector if it can't find the source files for an assembly. This would be a nice way to track problems into the framework (or other libraries). This is what I have to do today, but I do it in my head, which doesn't really work.