How to dynamically execute code written inside Visual Studio

Just posted this GitHub issue How to dynamically execute a code written from Visual Studio with the answer (written as a blog post)

O2Platform question on 'Interactive development with Visual Studio'

Here is a reply I posted today to the O2 Platform Mailing list regarding a question about 'How to use O2 inside VisualStudio and WPF support' (with lots of links to code samples and blog posts)

---

Hi Chris, I'm glad you found the O2 Platform, specially since it looks like it already have the main features you are looking for :)

The key concept used across the main O2 Platform (and FluentSharp) APIs is the REPL (Read Eval Print Loop), which should be very common to you (btw you can run .Net's version of Lisp via this O2 script : Util - Clojure-clr REPL (Lisp).h2 )

Using Chrome inside a native VisualStudio pane (using Window Handle Hijacking)

To help me debug and visualize an AngularJS page I was developing, I used the O2’s Window Handle Hijack technique to insert an Chrome window inside VisualStudio 2010.

Here it is in action:

VisualStudio 2010 crash

This shouldn't happen inside this VisualStudio dll:

Creating a Server-Side Google Analytics data submitter (in VisualStudio using C# REPL)

Following from Sending messages to TeamCity and UnitTest to check if the Google Analytics file has changed post, now that we have the ga.js hosted on TeamMentor’s code base (used to handle the original client side request), we need to add the ability to submit server-side data to Google Analytics (GA).

To do that we will need to replicate the client-site (JavaScript based) request sent to GA (Google Analytics) servers.

Writing custom C# scripts when Edit-and-Continue is not possible

Due to limitations of Edit-and-Continue, we can’t make code changes here:

Using VisualStudio C# REPL to quickly find issue

While refactoring a TeamMentor UnitTest, I hit on this error:

Just Uninstalled ReSharper

The performance hit was just too much, and since I got a reply from JustCode I will give it another try

Just tried JustCode and its a shame they don't support ExtensionMethods

I just gave JustCode VisualStudio Extension a test drive (which amazingly still hasn't entered the SAST market) and although I really liked what I saw (and felt much better/faster than resharper) it had a critical problem, where it failed to recognise the FluentSharp's Extension Methods in TeamMentor:

IBM AppScan Standard, Source and VisualStudio (in the same GUI/App)

Here are some cool screenshots sent to me by an O2 user, that used the technique shown in Using a .Net/CLR, a Java/JVM and a C++ Window in another process (to show consolidated security findings) to create a GUI, where windows from AppScan Standard (.Net app), AppScan Source (Java app) and VisualStudio (C++/.NET/WPF app) are shown side by-by-side (fully functional) in an external process.

Bellow you can see the four Windows in action:

• Top Left: Findings TreeView from AppScan Standard (.Net)
• Top Right: Code Editor from VisualStudio (C++/WPF)
• Bottom Left: Trace View from AppScan Source (Java)
• Bottom Right: Guidance from AppScan Standard (WebBrowser)

Why doesn't VisualStudio (or .NET) have StackOverflow Detection?

It's crazy the fact that one simple mistake in one thread (a recursive call to itself) will bring the entire .Net process down!!!

Formatting code for readability

On the theme of making things better and caring about the parts that can't be seen, here is an example of how I like to format large groups of .Net methods (so that they are easier to read and to look at)

Here is what a .Net Class usually looks like (if you allow VisualStudio to format it)

Another VS 2010 crash

It should not be possible to crash apps like VisualStudio. That kind of mission critical app should have a number of anti-crash protections.

But VisualStudio is a massive salad of technologies (see images at the end), and amazingly (bad) it allows its extension's errors to crash the whole app (which again should not happen). 

During my regular use of VisualStudio, I get all sorts of errors/crashes, for example here is the latest one (without any other extensions installed):

Improved script to compile and show an modified UserControl inside VisualStudio

Here is an updated version of the example described in the Real-time Programming C# WinForms Controls in VisualStudio's IDE (i.e. without using F5) post.

Viewing 'Console Out' messages created inside UserControls (when rendered by VisualStudio's Form Designer)

Now that we have the ability to Add 'Console Out' to VisualStudio IDE as a native Window the question is: "Where can we use Console.WriteLine inside VisualStudio?",  in a way that the written lines/chars show in that Console Out window:

The key to understand the question is to visualize this:

• The Console Out window is running inside VisualStudio (i.e. in the same process)
• The Console Out window script captured the VisualStudio process' Console Out (of which there is only one, and the reason why if you open multiple Console Out windows (as shown above) only the last one opened will capture the output
• To send a message to Console Out window the sender (i.e. the code executed) must be inside the same VisualStudio Process
• This means that (based on quick tests) VisualStudio scripting engines (like the Immediate Window or the F# interpreter) will not work (since they are running outside the VisualStudio process)

One easy way to trigger an Console.WriteLine is to write it in one of the C# REPL script GUIs (from the O2 VisualStudio Extension) :)

But what would be really useful would be to trigger Console.WriteLine debug messages during normal VisualStudio development, for example when programming WinForms Controls :)

To show how that is possible, lets start with an empty WinForms Application project:

Which comes with default WinForms Form:

Next add a UserControl with a Label:

And add that UserControl to the Form:

The interesting part of what just happened, is that VisualStudio invokes the constructor of the UserControl1.cs (in order to create a live instance of that Control) before adding it to the Form1.cs object.

And that (the UserControl1.cs constructor) is where we can trigger the Console.WriteLine calls.

Open the Code Behind file for the UserControl1.cs file:

Write a Console.Write message and build the project (note the message shown in the Console Out window)

The reason that happened, is because (after a successful build) VisualStudio needs to refresh the controls currently shown in the Form's Designer (for example to take into account any visual changes in those controls)

Here is another way to trigger the Console.WriteLine call (i.e. to trigger the UserControl.cs constructor).

Close Form1.cs from the Form Designer:

And the open it again:

Yet another option is to delete the UserControl1.cs from the Form1.cs:

And add it back again:

Basically, the UserControl1.cs constructor will be invoked every time that control is added (or shown), like in the image below, where another instance of UserControl1.cs was dragged into the Form1.cs:

Interestingly enough, this as a number of security implications, since a security payload/exploit can be triggered just by adding/viewing a UserControl inside the Form Designer. The problem is that the payload will run with the same privileges given to VisualStudio (not the privileges used to run the application)

Adding 'Console Out' to VisualStudio IDE as a native Window

Michael Hidalgo has posted two blog entries where he uses the O2's VisualStudio Extension to open an Console Out window inside VisualStudio, which is then used to help with a quick test on the DateTime object (and making his life easier)

• How to use the Console output in the C# REPL  (in the O2 blog)
• Making Software Developers life easier : Using O2 Platform as a fast development framework (in his blog)

Micheal is using the API_ConsoleOut.cs (which you can read in more detail at API_ConsoleOut.cs – New and InProcess Capture of the Console Output ) to add a 'Console Out' Panel to a Form Window.

Now this Form object is a WinForms control and is not a native VisualStudio Window, which means that we can't add it to the VisualStudio Panes.

A better option is to make this a native VisualStudio Window, which is quite easy to do.

Open the C# REPL - VisualStudio 2010 API (from the REPL menu)

And with the VisualStudio_2010 object:

Create a native VisualStudio window (with a WinForms Panel inside it):

Use the same add_ConsoleOut extension method on the Panel object (the one returned by the open_Panel extension method):

And now the Console Out is now inside a native VisualStudio window, which we can access and manipulate.

Here is an example of changing the base window's width, height, top and left values:

Which of course we can now put anywhere inside VisualStudio's GUI

Next see the Viewing 'Console Out' messages created inside UserControls (when rendered by VisualStudio's Form Designer) for a practical example of using this technique during development.

Improving VisualStudio productivity by compiling and executing code from the IDE

The Real-time Programming C# WinForms Controls in VisualStudio's IDE (i.e. without using F5) blog entry shows how to use the VisualStudio C# REPL - O2 Platform extension to update/fix an existing WinForms control without going through the painful (and slow) process of VisualStudio GUI programming.

What you will see in that example is that I will dynamically compile and execute a WinForms Control, without using VisualStudio's Debug/Run capabilities to see the new changes in action. I was able to compile the modified Source Code file, and using reflection, was able to create a new instance of an WinForm's Control (without leaving the VisualStudio's IDE).

And the best part is that we can code our tests in an REPL environment (think Roslyn), which allows the support for complex (and unit-test like) scenarios.

I can't underestimate how powerful, fast and efficient it is to be able to have this type of REPL environment while coding.

This is what I would like to see on the next version of VisualStudio.

Real-time Programming C# WinForms Controls in VisualStudio's IDE (i.e. without using F5)

Here is an example of using the VisualStudio C# REPL - O2 Platform extension to update/fix an existing  WinForms control without going though the painful (and slow) process of VisualStudio GUI programming, which usually goes something like this:

• Coding + Compiling + F5 + Wait for App to Load + Going to Control + Testing it + Stopping 
• Coding + Compiling + F5 + Wait for App to Load + Going to Control + Testing it + Stopping 
• Coding + Compiling  + ....

We start with the O2 Platform Solution loaded in VisualStudio 2010, with the projects from the O2.FluentSharp and O2.Platform.Projects repositories, and the VisualStudio C# REPL - O2 Platform extension installed (note the extra REPL menu)

From the REPL menu, chose the C# REPL - 'Hello World' menu option:

Which looks like this (it's a good idea to right-click on the code editor to open the context menu, and to select the show Log Viewer option:

Here is a small text change to show the C# REPL environment in action

Now here is the powerful part, this script:

Will create a new popup window with the ascx_Simple_Script_Editor WinForms Control (that was just dynamically compiled from the original source code (note: the ascx_Simple_Script_Editor Control is the one used to create the C# REPL environment))

What is happening is that the ascx_Simple_Script_editor.cs file (whose source code is shown in the background) was dynamically compiled and executed .... without leaving the VisualStudio's IDE.


Just to double-check that we are doing this in real time, lets make a small code change in the  ascx_Simple_Script_editor.cs source code (using VisualStudio's code editor).

The code shown below will create two MessageBox(es). The first was created using the normal .Net MessageBox call syntax,  and the 2nd uses O2's FluentSharp API (which should be easier to read)

Here is the 1st MessageBox:

Here is the 2nd MessageBox:

The ascx_Simple_Script_Editor WinForms Control will appear after the MessageBox(es):

Now that we've proven that we are able to change, compile and execute a C# WinForm's control in a REPL environment, let's do something more interesting.

Moving a ToolStrip Control

One of the O2 Platform user's feature requests that I have received for this control (the one that we are editing), is to move the ToolStrip Control  (the one with the New, Open and Save As buttons) from the bottom of the Control,  to the top (which is where usually ToolStrips are located).

Going back to the VisualStudio document with the ascx_Simple_Script_editor.cs source code, here is the addToolStrip method that 'inserts below' the commandsToExecute Control an ToolStrip Control (the rest of the addToolStrip method adds the TootlStrip items (3x Buttons, 1x Label and 1x TextBox)

To change the location of the ToolStrip Control, we will use the FluentSharp insert_Above Extension Method  (vs the originally used insert_Below Extension Method)  :

Once the change is saved, we can immediately see these changes in action, by using the REPL environment created via the gist script shown above..

Here is the updated version of the ascx_Simple_Script_editor Control with the ToolStrip Control at the top.

Note that I didn't use VisualStudio's Debug/Run capabilities to see the new changes in action. I was able to compile the modifed Source Code file, and using reflection, was able to  create a new instance of that WinForm's Control (with everything done inside VisualStudio's IDE).

Adding a new Button

As a final example, lets add a Run button to the ToolStrip Control.

Here is the updated source code (note the new add_Button line)

Once saved , complied and executed (not by VisualStudio), we can see that there is a Run button on the ToolStrip.

Here is the button being used to execute a test REPL script:

VisualStudio power is still all there

Another benefit of this technique/workflow is that we still have access to the powerful VisualStudio Intellisense and Error detection:

Compiling and executing the Solution

The final step is to compile the Solution file (with the changes made)

And run the O2 Platform executable (now using VisualStudio's F5).

Note how the O2 Platform's native C# REPL editor now has the changes made to the ToolStrip Control (it is above the code-editor and has an extra Run button)

This technique will change the way you code (once you got your head around it)

I can't underestimate how powerful, fast and efficient it is to be able to have this type of  REPL environment while coding (and how painful is the VisualStudio workflow in comparison).

In fact, this REPL environment is a curse, since once you tried it, there is no way back! :)

This is why I say that I develop O2 in O2 :)

In VisualStudio - quickly adding a Menu and hooking the build process

The VisualStudio Extension and EnvDTE APIs are really hard to get into (and there are number of gotchas like the need to pin the events objects or they will stop working).

To make life easier (and more productive) the O2 VisualStudio FluentAPI tries to abstract all that complexity into easy to use and fast ExtensionMethods.

For example here is a script that shows how to add a menu item and hook  the build process:



You can execute that script in real-time using the VisualStudio C# REPL Extension , or by using the FluentSharp - VisualStudio2010 NuGet package on your project.

The source code is all on GitHub and for reference here are the Extension APIs on a number of VisualStudio Extension Objects (like EnvDTE)

Programming VisualStudio in real-time using C# REPL (do other IDEs also support this?)

The recently published O2 VisualStudio Extension provides a REPL environment inside VisualStudio (namely a C# REPL Environment with a Fluent API for .NET and VisualStudio)

In practice this means that in addition to being able to write and execute quick C# snippets (in a REPL environment), I can program VisualStudio IDE in real time! See this VisualStudio C# REPL page or this Reddit thread for code samples.

This makes a massive difference when developing/extending an IDE since there is no 'code+compile+execute' loop (which can take minutes). There is only a real-time REPL (Read Excecute Print Loop) directly on the IDE.

I believe this is the first real-time IDE coding in VisualStudio (at least without starting VS in a special experimental mode), so my question is:

Is there something equal or similar for other IDEs?

Namely for Eclipse?

Part of the reason I'm asking this question, is that I created the TeamMentor VisualStudio with CatNet using this VisualStudio C# REPL Extension (by coding the Cat.NET scanner integration with TeamMentor in real-time in the IDE), and I need to create a similar extensions for a number of other IDEs (and for example, don't really want to go through the pain of writing an Eclipse plug-in using the current documented/recommended process (see Your First Plug-in Developing the Eclipse "Hello World" plug-in for an example))

Just to clarify what I mean by real-time coding on the IDE, the script below will be compiled and executed direcly on VisualStudio (the IDE),  from an VisualStudio panel window and will change the VisualStudio state/GUI: