Instant 0.1

Wow. The response to my previous post on Instant has been amazing. Not just the abundance of positive feedback, but the great ideas in where this can go too. I said I’d release the source once I’d done a little cleanup, and today’s the day; admittedly long after I originally thought. Don’t expect a work of art though, this is hack-filled prototype code.


As I can’t distribute Roslyn, you’ll need to build the standalone prototype or Visual Studio extension yourself. The standalone doesn’t quite match the extension as that’s where my focus has been. They can be further unified by reusing the views / view models from the extension, but I haven’t gotten around to it.


I can’t stress enough that the current prototype is extremely limited. I’ve mentioned this here and there, but I want to make it abundantly clear before people start trying to use this. Some of the limitations are (at least in theory) temporary, and some are out of scope.

Single method only

As you may have noticed in the video, Instant currently only supports isolated methods. They don’t have to be static, but any access to the containing class or other classes in your project will fail.

Why? Primarily it has to do with my use of Roslyn’s ScriptEngine for the actual execution of the code. ScriptEngine is not terribly sophisticated (and understandably so), so it falls short for my use case here. This limitation is one of the remaining large hurdles; while it’s not terribly difficult to compile a proper assembly and execute some code, it is a different story when you’re trying to do this for full projects rapidly.

Side effects

Nothing in Instant will prevent you from accessing the disk, network or any form of IO where you can make real side-effects. This is simply a case of a problem that is out of scope. I do not have any plans to tackle the side-effect issue because I believe there’s enough use for methods which do not incur such effects. I would recommend not attempting to use it for these types of methods. Given the current execution engine, nothing will prevent you from calling Environment.Exit and killing Visual Studio either.


Currently the hooking mechanism can track (in theory, untested) multiple threads. However, the visualization has no support for displaying multiple threads so only the first one found will be displayed.

Infinite Loops

Currently, Instant does its best to cut off infinite loops early. The mechanism is far from perfect (and will likely never be), which means you will get both false-positives and false-negatives.

Why do this? The primary reason is memory. Given today’s quad and hexacore processors, a runaway process is generally no big deal since it will get canceled on the next submission. Problem is, it’s chewing away at memory recording the state changes during that process and will not be able to show you any information until it finishes.

There’s a few things that eventually we could do to help this, but it will a constant problem. First, we can start persisting the state changes to disk. We need to be very careful with this though, a runaway file on disk (especially solid states) is not much better than memory. Furthermore, we would not want this as the default given the extra latency between typing -> execution -> displaying results. Secondly, we could start visualizations as soon as results come in, allowing you to step through whatever loops have been completed so-far.


The Visual Studio extension performs worse than it should (as compared to the standalone). I’m new to the VS API and I expect (and in some cases, know) I’m doing a few things that are killing performance here. It hasn’t been a priority so far, but it will get better over time I’m sure. Note: I had to disable ReSharper in the experimental instance to get a sane level of performance.

How do I get it?

Now that I have the disclaimer out of the way:

What’s next?

Porting the instrumenting code to NRefactory. Roslyn’s current CTP license is extremely restrictive: It basically says I can not distribute it, and even if I could it would have to be for Windows only. This means I can’t just put Instant on the extension manager for all of you to play with easily, as that would be redistributing. Furthermore it means that even if Roslyn works on Mono, you wouldn’t be allowed to use it in MonoDevelop for OSX or Linux. Even if the Roslyn license were to change, I’d have to simply hope that it runs on Mono as-is. If it didn’t, I have no real recourse.

Another important next step is to support actual projects. Our first step to this is replacing the execution engine with something that can handle real assemblies, which shouldn’t be terribly hard. The hard part is narrowing the target compilation in some way so that we’re not trying to compile huge projects every keystroke. I expect to start with the full project to get that pipeline working and then start working on ways to narrow it down.

Previous Posts

This entry was posted in Instant, Projects and tagged , , , , , . Bookmark the permalink.

2 Responses to Instant 0.1

  1. Krzysztof says:

    “Porting the instrumenting code to NRefactory.” Great! That’s what I’ll be waiting for!

  2. Justin says:

    Glad to hear you are considering NRefactory. Up until you said that I was thinking that I would have to port it myself. Very cool project.

Leave a Reply

Your email address will not be published. Required fields are marked *