New blog location!

I’ve purchased some webspace so I figured I would move my blog onto to it as well. I’m currently working with some Android development and need a space in the cloud to host my data. Please update your bookmarks and visit often!

http://csharpening.net/blog

Surprise! PowerGUI VSX 1.1 – Beta 2

It’s been almost a month since I’ve posted anything about PowerGUI VSX (well…anything). I was on vacation, was pretty swamped at work and moved. But now that I’m a bit more settled I’ve found some time to work on a new  beta of PowerGUI VSX 1.1. Great surprises in this one! PowerGUI 2.2 Beta was recently released; which added native PowerShell debugging. I had to rework some of the PowerGUI VSX debugger to get this going correctly. I also fixed a slew of bugs and added some cool new additions. Here’s a list:

• Fixed a debug installation issue requiring Visual Studio to be run as Administrator the first time it is executed after installation of the VSX
• Added better Property window support to allow for examination of variable properties (and properties of properties, etc…)
• Added Comment\Uncomment\Indent\Unindent toolbar support
• Fixed a bug where renaming an open script file would continue to save to the old file location
• Fixed an issue where multiple tabs of the same script could be opened
• Tabs are now changed when debugging multiple scripts
• Found out that Express editions are not supported (they only support extensions with templates)
• Any cool things inherited from PowerGUI 2.2

Hopefully this drop is a lot easier to install. If you have any issues please let me know ASAP so I can get them handled (Issue tracker, blog messages, twitter, carrier pigeon…whatever). If you don’t have it already you will need PowerGUI 2.2 Beta for this release.

I hope to release a stable version pretty soon here. I’ll see what I can do about the remaining bugs in the backlog. Until then, grab this:

http://powerguivsx.codeplex.com/releases/view/51998

Stay tuned!

PowerGUI VSX Beta 1.1 Status

So Beta 1.1 has been out for about 2 weeks and I’ve received a few issues and the PowerGUI 2.2 Beta has been released. The changes to the debugger are really exciting. They should really help with the breakpoint management I was hoping to implement into the extension. I haven’t had much time to work on the VSX lately due to a busy schedule at work and the fact that I’ve been packing up and getting ready to move this coming weekend. Additionally, next week I will be out of town on vacation. The current build of the VSX is not compatible with Beta 2.2 of PowerGUI. The changes to the debugger are pretty substantial so I will need some time to rework some of the debugging components.  Once I’m a bit more settled in the coming weeks I hope to get a lot more traction on the issues that have been risen and add support for PowerGUI 2.2.

Here is a list of what is currently outstanding:

• No printing support from PowerGUI VSX (28535)
• No support for PowerGUI 2.2 Beta (28533)
• Bug with renaming script files (28532)
• Find and replace is still buggy (28499)
• Multiple tabs of the same script can be opened (28402)
• No automatic checkout (28169)

I apologize for the lack of updates regarding this project but once I have my free time back I will be working on correcting these issues. If anyone is willing to take a look at the code and possibly fix some of these issues feel free to email me directly or upload a patch.

Thanks for all the feedback and support! It is really awesome to have people checking this out.

PowerGUI VSX – Debugging a Debugger – Part 3

Well now that I officially released the PowerGUI VSX Beta 1.1 (twice) with the newly added debug engine I thought I would share how I accomplished the final stages of integration. In my last segment of this series I talked about launching the engine. Once the engine was launched I faced my next hurtle: breaking and stepping. These features are arguably the most crucial components of any modern debugger.  The Visual Studio debugging API has a ton of interfaces to allow for creating a really versatile engine with all the goodness that comes with debug engines that are baked into the IDE.

Interfaces of Interest

• IDebugPendingBreakpoint2, IDebugBoundBreakpoint2 - Pending and bound breakpoints notify the SDM when to cause the user interface to break
• IDebugThread2 - Retrieved from the IDebugProgramNode2 and break point events, this interface is used to denote a thread within a process.
• IDebugStackFrame2 - An enumeration of stack frames are returned by the thread to describe where in the call stack the current code is executing
• IDebugCodeContext2\IDebugDocumentContext2 - The code and document contexts describe to the editor where within a source file to position the debug cursor

When the user clicks the breakpoint margin in Visual Studio a break point is posted to the SDM in a pending state (as a IDebugPendingBreakpoint2). After the debug engine is loaded, it can enumerate the pending breakpoints to determine which breakpoints can be successfully bound; creating a IDebugBoundBreakpoint2 for each successful binding. When the PowerGUI debugger hits a break point, it sends an event to the VSX which then raises an IDebugBreakpointeEvent2. This debug event provides a IDebugThread2 to the SDM for further examination.

In the PowerGUI VSX debug engine I defined IDebugThread2 on the same class that I defined IDebugProgramNode2 and a host of other interfaces. I haven’t included the ability to debug multiple threads. It would be cool to debug asynchronous jobs this way but this is definitely something for version 2.

The debug thread provides a enumeration of stack frames. Each stack frame then provides the document and code contexts and any IDebugProperty2s that are valid at that scope.

That doesn’t sound hard, why’d it take you a month to do this?

Debugging a debugger proved trying. It was hard to discern what Visual Studio was expecting when something was amiss.  My only recourse was to include trace logging for every implemented method. This way I could trace exactly where my chain of calls was ending. Typically, with some messin around, I could move onto the next necessary call. I didn’t implement the debug engine like a typical language provider because all the user interface management is taken care of by PowerGUI.

If you open the breakpoints window within Visual Studio you will see that only 1 breakpoint exists.  Prior to starting my debug engine I call IVsDebugger.InsertBreakpointByName. This ensures that the SDM will allow my debug engine to bind this pending breakpoint and eventually notify it that the breakpoint has been hit.  This is another version 1 hack. It would be nice to expose breakpoint management through the Breakpoints window but for the time being this will suffice for enabling breakpoints to be hit.

Another reason for the delay was that once I implemented stack frame and context support it seemed that the engine would run off into the weeds and present the “No source code available window.” I grew to hate that thing. I debugged and debugged the debugger but could not identify why this kept happening. Eventually I realized the problem was with the editor not the debugger. Due to the fact that I’m letting PowerGUI run the show, I neglected implementing several key methods in the editor. Once these were complete debugging finally worked.

What next?

The fun stuff! Since the release of Beta 1.1 I’ve added better property support:

Locals window with expandable variables

I’ve also fixed an issue where the tabs would not change correctly when debugging multiple scripts. My next few items I’d like to see added are real stack frames, true breakpoint management, and Visual Studio exception dialogs on script failure. My final objective is to enable seamless .NET to PowerShell and PowerShell to .NET debugging.

I’d like to hear some feedback on how this engine is working for everyone out there and also what you’d like to see.

I’ll keep everyone posted on my progress so stay tuned!

PowerGUI VSX – Beta 1.1 Update

I’ve posted an update to Beta 1.1 due to issues surrounding installation of the debug engine. The engine needs to be copied into the PowerGUI installation folder because I can’t load the assembly myself. It relies on the PowerGUI assemblies so this is the only way it will be able to find them. It also needs to be registered with Visual Studio from that location. This installation will take place the first time the extension is initialized. Because of this installation and registration Visual Studio will need to be run as Administrator the first time after the extension is installed. Launching a PS1 file initializes the extension and the file will be copied and registered. From then on there should be no need to run Visual Studio as Administrator.

I know this is a bit hacky and is calling out for an installer. Due to the complexity of this release’s  functionality I foresee releasing another, more stable and complete, beta. Stay tuned for more information.

PowerGUI VSX – Beta 1.1 Release

After about a month of hard work on the PowerGUI VSX I’m releasing Beta 1.1. The download is available here, at the CodePlex site. Here are a few screen shots to get you excited:

The debugger honors breakpoints set into source files.

Basic variable values are presented in the locals window.

Output is written to the output window.

Getting the debugging working proved to be pretty difficult. Visual Studio loved to go off into the weeds with little information about why it was doing so. I’ll delve into the down and dirty in a later post so stay tuned for more information on that. In addition to getting debugging to work here is a list of some other bug fixes and features included in this release:

• Can now search for text
• Can now goto line
• The VSX now honors font settings
• The VSX now honors line numbering settings
• User prompts are presented during debugging
• A PS1 file template is included for CSharp and VB.NET project types to create new script files
• The script editor is now tied to PSM1 and PSD1 files as well as PS1 files
• The VSX can now be installed in all version of Visual Studio 2010

In addition to some fixes there are also some known issues:

• When debugging multi-script sessions the debugger does not switch tabs automatically (annoying I know…)
• The locals variables rely on ToString() to present values so complex objects may yield little information

I know more issues will crop up so please let me know as soon as you run into something either on the discussion forum, by adding an issue to the issue tracker or by leaving a comment on this blog. I’m a bit concerned about installation issues because the VSX requires a COM registration and some kind of complex registry work to get the debug engine installed correctly so I’d especially like to hear feedback about that.

To launch the debugger, select the desired script and press Shift+F5 while in the window. From there all the normal debugging keys will work (F5, F10, F11).

Stay Tuned!

EDIT:

You will need to copy the file PowerGUIVSX.Core.DebugEngine.dll from (C:\users\<user name>\AppData\Local\Microsoft\VisualSTudio\10\Extensions\Adam Driscoll\Power GUI Visual Studio Extension\1.0) to the PowerGUI installation folder (C:\Program Files (x86)\PowerGUI).

Unfortunately this may not be the only installation issue. I’ll keep you posted…

PowerGUI VSX Beta 1.1 – Bad News

I know I promised a beta release this week but the programming gods have worked against me. I didn’t accomplish everything I wanted for the beta so I’ve decided to hold off until I have a chance to produce a more complete product. As always you can still grab the latest source change set and build it yourself. Just to keep you interested here is what will be included in Beta 1.1:

• Support for all versions of Visual Studio 2010 (Item #27928)
• Item templates for PS1 files (Changeset 72433)
• Support for PSD1 and PSM1 files (Changeset 73496)
• Fixed a bug where searching would not work (Changeset  72343)
• Fixed a bug where font settings were not honored in the VSX editor (Changeset 73598)

What I’m trying to accomplish before Beta 1.1 is to get the debug engine functional. Currently I have the engine launching, running scripts and writing output to the VS output window. I’m on the verge of implementing breakpoints and stepping. Once this is complete I will release Beta 1.1.

Stay tuned!