When I first heard that macros were being dropped from Dev 11 I was gobsmacked. (I just love that world!) While the macro story up to Visual Studio 2010 wasn’t great because we couldn’t write macros in our .NET language of choice, I expected the situation would start getting better and was saddened when the fix was to remove the easy customizability all together.

People at Microsoft said that the code behind macros was too brittle to update and their telemetry said macros are feature no one was using. My theory is the reason people skipped macros are because you had to do it in a different language. (VB people: I’m not criticizing VB but most of the developers who would write macros are C#/C++ developers). By dropping macros, the argument was that there was still a valid way to extend the development environment with .VSX files. That’s great but like I really want to install an SDK, write a VSX and have Dev 11 debugging Dev 11 just to enumerate my projects and add a new define to debug build configurations.

Readers of this blog know I’ve written many macros (examples here) that make debugging in particular easier. I use my macros on a daily basis so was not looking forward to porting them to an extension and all the junk that entails. As I was navigating the file system using the now built in NuGet Package Manager Console window, why not use PowerShell as the macro language? While this works, I’ll still be pestering Microsoft a lot during the Dev 12 development cycle for a real macro system that lets me program in any .NET language.

To use PowerShell as the macro language, you need access to the Visual Studio automation model. In macros and extensions the root of life is the DTE interface. A quick look at the variables defined in the Package Manager Console shows a $dte variable so once you have that, you’ve got everything! That’s nice when things are easy.

My goal was to port all my macros over to PowerShell and you can see the results of my porting efforts at the bottom of this blog entry. For the most part, it was simply a matter of porting VB to PowerShell, which wasn’t too onerous if you know PowerShell. The main drawback I encountered is that to debug any functions you write you have to use the old PowerShell 1.0 way of debugging with Set-PSDebug and all the fun of command line debugging. It’s a bit painful, but it does work.

There were two areas where I got stumped during the porting. The first was in converting interfaces. When accessing the breakpoints in PowerShell, you use $dte.Debugger.Breakpoints. However, that returns the original IBreakpoints interface defined back in Visual Studio 2003. However, if you want to access the Filterby property, you need the IBreakpoints2 interface defined in Visual Studio 2005. As PowerShell’s COM implementation only works with IDispatch, and not explicit interface members, I was not sure I could get everything to work if I couldn’t convert. Fortunately, the NuGet developers already thought of this and provided the Get-Interface cmdlet that allows easy conversion. The following snippet shows converting an IBreakpoints interface into the IBreakpoints2 interface.

The second problem in porting I encountered was trying to use a Visual Studio method like $dte.Breakpoints.Add, which takes many optional and conflicting parameters. That’s easy to do in VB, but PowerShell sort of likes you to use all the parameters to a COM method. A bit of careful web searching lead me to a great solution by Jason Archer where he uses some seriously ninja PowerShell tricks to solve the problem. If you want to learn some advanced PowerShell, look at Invoke-NamedParameter function.

By using the Package Manager Console, I thought packaging up my cmdlets as a NuGet package would be the way to go. The only problem is that a NuGet package is designed to be used with a solution, which is the correct approach, but I wanted my cmdlets to be available at all times. To that end I chose to go with a PowerShell module, which works just fine with the Package Manager Console.

You can put the files in the download anywhere you want, but if you would like to include them in the module path, use Install-Module.PS1 to do the installation.

It looks like there’s a bug in the NuGet Package Manager Console because the $ENV:PSModulePath does not include the normal user’s documents directory in the default path. Consequently, to run Install-Module.PS1 you will need to run Dev 11 elevated to do the installation as the NuGet modules directory is in Program Files.

If you’re still using Visual Studio 2010 and you want to try out my cmdlets, please do as they all work provided you installed NuGet. If you have any questions or ideas for other macros, please don’t hesitate to let me know.

Download WintellectVSCmdlets.

We are growing like crazy at Wintellect and want you to work for us! We’d prefer full time employment, but would be happy to also work with some of you excellent independent contractors. At this time we need candidates to be based in North America. What we are looking for are excellent project managers and developers who thrive on challenging work, can work independently, and have excellent communications skills. We don’t care where you live in North America either as we have people all over the US.

The raw skills we want are ASP.NET MVC, C#, SQL, and WCF. If you’ve just read about those technologies in a book (maybe even one we wrote), that’s not good enough. You need to have a track record of shipping code and open source counts big with us. Please forward your resume and availability to Barbara Keihm, Director of Human Resources, bkeihm@wintellect.com.

With Dev 11 Beta now in our hot little hands, I needed to update my symbol server and source server PowerShell scripts that automate setting up a developer machine. I’ve packaged up all the scripts previously published on this blog into a module, WintellectPowerShell, to make the cmdlets easier to use.

To set up a development machine to use a symbol server, use the Set-SymbolServer command. It takes care of setting the _NT_SYMBOL_PATH environment variable, as well as Visual Studio 2010 and Dev 11 Beta provided they are installed. The Set-SourceServer command sets up both VS 2010 and Dev 11, but also will set the _NT_SOURCE_PATH environment variable so WinDBG can pick up the source from your version control system as well. Yes, you C++ folks, these scripts support you as well!

I’ve also included an update version of my Get-SysinternalsSuite script that will download and extract all the wonderful Sysinternals tools. My previous version of the script relied on an external zip tool, but now used the Shell’s zip provider. There are a few other commands in the module for getting the current symbol server and source server values. The help is shown below and the download is here.

As always let me know if you find any bugs or have suggestions!

No discussion of PowerShell would be complete without a one-liner that does a lot. I wanted to show the help in this post so you could see all the commands. Once you have a module loaded, you can get the help simply by doing the following:

I thought that was pretty cool!

One of these days Microsoft will release a version of .NET where we don’t have to worry about memory. HA! Who am I kidding!? All you worry about in a .NET application is the memory. Naturally, I personally never want Microsoft to come out with the memory worry free .NET because I’d be out of a job.

With SOS for .NET 4.5, there’s not a whole lot different but there are two differences that will be valuable. The first are two new options to the most important SOS command, !dumpheap. One of the big problems in dealing with those minidumps from production systems is trying to figure out which objects are rooted, meaning have references and cannot be garbage collected, and those objects that are ready for garbage collection. That problem is easy to solve with the new –live and –dead options. Get in the habit now of always passing –live when you first do that initial !dumpheap –stat because that’s all you care about!

Here’s an example output comparing the differences reported by –stat alone, -live, and –dead.

What I haven’t been able to figure out is that the total objects between live and dead objects never add up to the total shown when looking at all objects with just the –stat switch. Doing some experimentation the output for –live looks valid so I’m going to trust it for now. I’ll talk to the CLR team and see if this is a bug or there’s a real reason for the discrepancy. It’s not like an object could be alive and dead at the same time… unless it was a ZOMBIE! No matter, the –live switch looks fantastic and will save everyone a huge amount of time.

Since everyone is not moving over to .NET 4.5 immediately, I tried like crazy to see if I could get the .NET 4.5 SOS version working with minidumps from .NET 4.0. Nothing I tried and no amount of playing around with .cordll to load the MSCORDACWKS.DLL from .NET 4.0 would work. Do yourself a favor now and make sure you save off SOS.DLL, CLR.DLL, and MSCORDACWKS.DLL from a pure .NET 4.0 installation because .NET 4.5 is on top of .NET 4.0. I’ll keep working on trying more tricks to get !dumpheap –live working with .NET 4.0.

The second SOS command to get some development love is !clrstack. There’s a new experimental option –i, which uses the CLR Debugging API’s ICorDebug interface to walk stacks and show variable names very much like the !mk command in SOSEX. It’s very important that to use !clrstack –i you have the _NT_SYMBOL_PATH environment variable set to include the public Microsoft symbol server. SOS needs access to MSCORDBI.DLL through the symbol server download even though that DLL is in the framework directory along with SOS.DLL.

Running !clrstack –a –i will show output like the following snippet. What you can’t see is that the output is that it’s fully DML ready.

You are probably wondering where the actual values are. Just like !mk, when it’s JIT optimized code we can’t get the values. That doesn’t make !clrstack –i any less valuable because at least it shows you the types so you can use !dso, or !mdso from SOSEX, to look them up. To turn off the JIT optimizations, you’d have to either run the whole application with the COMPLUS_ZAPDISABLE environment variable or turn it off for an individual assembly with the INI file trick.

The new –live and –dead options for !dumpheap and the –i for !clrstack are the most important additions, but there are a few more worth mentioning. The !bpmd command now supports setting breakpoints on a source and line if you have the PDB file for the assembly loaded. If you’re doing heavy interop, the new !dumprcw, which dumps a Runtime Callable Wrapper, and !dumpccw, which dumps a COM Callable Wrapper, look helpful. The new SOS for .NET 4.5 is nice, but wait until you see the new version of SOSEX!

Dev 11 has a diff and merge view that is simply outstanding and using it to compare changes before checkin is just dreamy. I ran into a situation where I wanted to diff the output of two files and thought that it would be nice if I could do that in Dev 11. Popping into CTRL+Q and typing “diff” just says, “No search results available”, which isn’t very helpful.

Figuring there had to be a command related to diffing, I looked up all the commands in the Keyboard Options page and ran into Tools.DiffFiles. Running that in the Command Windows did nothing so going for broke, I typed “Tools.DiffFiles c:\” and got a nice little autocomplete popup to choose the file. Obviously, Tools.DiffFiles takes two parameters, the first being the left side file, or the source, and the second being the right side file, or the target. Below shows an example from the Command Window

That’s great we’ve got the ability to do random diffs inside the IDE, but being a command line guy, I want to do the diffs directly from PowerShell even if Dev 11 isn’t running. It turned out to be far easier than I ever imagined. Checking the command line options to DEVENV.EXE, by running “devenv /?” showed there’s a new command line switch. /diff, that does exactly what I wanted. So anytime you want to use the Dev 11 diff tool, run the following:

If Dev 11 is running, you’ll get a new diff window in the running instance, otherwise, you’ll get a new copy of the IDE. Of course, you’ll need devenv.exe in the path so run VCVARSALL.BAT to get it in your path.

Realizing I hadn’t updated my build server that ran against TFS Preview to the Beta Dev 11 TFS, I upgraded the machine and ran into a problem. The first queued build stuck and could not be canceled or deleted from the queue, thus blocking all builds. With an on premises TFS you can go into the SQL database and change the state of the build, but last I checked Microsoft won’t let us access our TFS Preview hosted SQL tables with SQL Management Studio.

My scenario was a build controller running the Dev 11 Developer Preview TFS that was upgraded in place to the Dev 11 Beta TFS bits and kicking off builds from Visual Studio 2010. Since most of you will start with fresh Dev 11 Beta bits, I doubt anyone will run into the situation I had but will post the solution for karma points from the one other person who hits this.

The upgrade itself went great and I was able to see the build servers from VS 2010. I checked in some changes that triggered a CI build and after 20 minutes saw that nothing had happened in the build. In Visual Studio 2010 I tried to cancel the build but no status changed. In the TFS Preview web site trying to cancel the build reported an error: “TFS.ServerException: TF215067: Cannot cancel queued build 48 on build controller BUILDSERVER - Controller. The current status is In Progress and queued builds can only be canceled if the status is either Postponed or Queued.” Shutting down Visual Studio, the build controller machine didn’t help either. Because of the stuck build, I couldn’t delete the build controller either.

Firing up a new machine (named COMPILESERVER), I installed the Dev 11 Beta TFS and configured a new build server and said to replace an existing build server (named BUILDSERVER). That transferred the stuck build to COMPILESERVER. On BUILDSERVER, I unregistered the build server and removed the build server feature through the TFS Admin Console. Still on BUILDSERVER, I added back the build server feature and configured this to be a second build server against my TFS Preview hosted collection.

Back in Visual Studio 2010, I queued up a new build against the updated BUILDSERVER and the stuck queued build immediately vanished. My new build worked fine and I was able to remove the build server from COMPILESERVER.

So today is the day everyone gets to see if that monochrome/metro UI look for Visual Studio Dev 11 works. Given the huge number of “constructive criticism” comments  that everyone gave on the first look it will be very interesting to see what people think once they get their hands on it. Because of some work I am doing I’ve been using some of the beta builds full time for the last couple of weeks. In this post I want to give you some impressions and point you to a couple of key features that I’ve fallen in love with.

In a nutshell, the overall new UI look is quite dull and I feel even stronger that color needs to be added back. One of the new UI changes I do very much love the blue highlight around the tool window that has focus. Now you know instantly which window where your typing will go and I wish that window focus hint could be back ported to Visual Studio 2010. While I’m getting better at what some of those black on grey icons do, I’m having to stop much more with the mouse hovering over the button to see what it does through the tool tip. I’d love to see how the methodology of the iconography study mentioned in the initial blog post because I haven’t talked to too many people who can recognize many of them at a glance.

What bothers me most about the new UI kerfuffle is the marketing failure on how the changes were announced. There’s nothing wrong with moving my cheese  if it’s going to make my life better. There are so many amazing changes for the better in Dev 11 that you will not only gladly have your cheese moved, you’ll happily change the flavor. I was frankly shocked that the first pieces of information about the Beta shown were static screen shots (with a ton of cheese moving for no apparent benefit) and emphasis on minor features. The second blog entry on the UI was better as it focused on usable features such as the Hub and Pivots, but those are still smaller features compared to everything else in the Dev 11 Beta.

Marketing 101, and common sense, says to go out with the strongest best features first. By having the first look being something divisive and not showing off what’s amazing about the product, the poor impression lingers and hurts everything else being announced. Compounding this marketing misstep was Microsoft’s recent history of jerking around the development community a little over Windows 8 and massively with Silverlight. As developers who’ve bet our careers and companies on Microsoft we can’t afford many more marketing screw-ups like we’ve been seeing lately. Make no mistake they’ve built another great release of our every day tool. My main feature request for the release after Dev 11 is for marketing and management to shove everything else aside and have an actual plan that all changes must make the majority of users day to day work demonstrably easier and more productive. If it doesn’t meet those criteria, it’s cut immediately.

I’m sorry for going off on the sidetrack about marketing, but I really do feel it is the weakest part of Dev 11. You came hear to read about the experience of using the new Beta. Since there’s going to be tons of information about these features from Microsoft today I won’t go into details about usage but want mention a few key features that have delighted me to no end as I’ve been using Dev 11 and ones you should concentrate on.

One feature in particular needs a proper introduction: THE UNIT TESTING TOOLS IN DEV 11 ARE BEYOND H*@#Y S&#@T F@#&!!*G AWESOME! (I apologize for that outburst but I can’t help it.) While the tools have been pretty good for .NET development, albeit with some very sharp and painful edges, the new unit testing across all languages, including native C++, integrates seamlessly with your day-to-day work. I moved over a fairly large C++ project and was thrilled to see it’s trivial to implement tests and has the same integration as .NET. Everything is first class now and the Run Tests After Build is so obvious I don’t know how we lived without it!

Moving over a large .NET project with existing unit tests using MSTEST was obviously trivial. What I’ve loved is that the team added support for other unit testing tools like xUnit. This means that say someone comes up with a unit testing tool for JavaScript or databases, it will be extremely easy to integrate. This is going to be a huge win for the future.

With many of us using TFS as our ALM system it’s nice to see a lot of love given to the friction points in dealing with tasks, bugs, and version control. The new Team Explorer Pane is simply sublime. All the modal dialog hell that used to be TFS is all gone and many things now happen in the background like check in, search, and automatic updating of pending changes. It really is a radical rethink of the entire usage model for team development. At your fingertips you have everything you need to see what’s happening. My new favorite keystrokes all start with CTRL+0 (that’s zero) because to get to the pending changes in the Team Explorer Pane is CTRL+0, P, where the builds are CTRL+0,B and so on.

Another feature related to TFS is the shift to local workspaces. In VS 2010, working with TFS was mostly OK if you were permanently connected to your TFS server. Trying to work offline from your TFS server was pretty painful as it was up to you to manage adding and removing files. Don’t get me started on the reliance on the read only flag for files or file changes from external tools weren’t picked up. Compared to the SVN experience, TFS wasn’t so great.

That’s all changed as with local workspaces, there’s really no difference between online and offline mode. You work with your projects anywhere and any changes made by you in VS or a quick change to a file with Notepad2 are automatically seen and ready to go as soon as you connect back to your TFS server.

What you’ll see different on your disk is a directory called $tfs under the root of the top workspace directory. That’s where TFS stores super compressed versions of the files and data. A background file watcher scans the differences between this cache and the file system to automatically pick up all pending changes including file updates, adds, and deletes. The VS 2010 way of finding updates was to pull up the Pending Changes dialog and look for all the changes by pounding on the server. Now the client does the work a tiny bit at the time so you have a real time view. It’s kind of hard to describe just how nice it is to just work with your projects and code with all changes ready to check in at a moments notice.

As someone who loves all things debugging and profiling, the new IntelliTrace the new standalone collector is going to change your life. Being able to capture a “video” of your application in production instead of just a minidump is huge. It’s actually very easy to use and Microsoft has already posted a page that shows all the steps: http://msdn.microsoft.com/en-us/library/hh398365(v=VS.110).aspx. With rich PowerShell support just go ahead and make the stand-alone IntelliTrace collector part of your standard server install so it’s ready at a moments notice. You’ll want to set up training for your network administrators so they can start collecting the “videos” as soon as they see a problem.

Let me make very clear that I do feel that Dev 11 is a hugely valuable release and something you’ll quickly fall in love with because of features that will make your life better. I know Microsoft has heard us regarding color so I suspect things will get brighter in the future, no pun intended. The real test of the value of Dev 11 is that I don’t like going back to Visual Studio 2010.

So I guess February 29th ought to be quite interesting with Windows 8 Consumer Preview and VS 11 being released. An even more important date is Monday February 27th as that’s when we are holding a Wintellect Tweetup where we want to hear your thoughts on all the new announcements. We’ll have fellow Wintellectuals, Jeremy Likness, Steve Porter, and Jeffrey Richter there to stir the debate. The event will be at Parlor Billiards and  Spirits in Bellevue. Hit the link to sign up.

Please note that this even IS NOT AT ALL limited to just MVPs! If you’re a Seattle-based developer you are more than invited as well. All NDAs (Non Disclosure Agreements) will be honored so we won’t be giving out any secrets so the Wintellect lawyers can breath a sigh of relief.

We look forward to chatting with you and getting your opinion of everything Microsoft!

Ed Blankenship has a brilliant idea to make symbol servers even easier to use. He wants TFS itself to serve up the symbols instead of requiring you to create the file share and fight with the network admins to get it backed up. Ed’s got a wonderful proposal on his blog about how the feature would look and work. If you can’t tell, I love this idea! With IntelliTrace about to become such a major feature of your life, anything to make getting the right symbols easier needs to be high on Microsoft’s priority list.

Go on over to UserVoice and vote so Microsoft knows you want this!

There’s a lot of UI research going on focused around better debugging. Debugger Canvas is some that you can use today and the version 1.1 was just released. The speed increased in 1.1 are great and make Debugger Canvas much more usable. I’m in love with the toggle button where you can flip between Debugger Canvas and regular text file display. While I have a few feature requests that I’d love to see, using 1.1 made me wish for some more. My feedback’s been given to the Debugger Canvas team but I thought it might spark some discussion by mentioning my additional wishes to everyone:

• When using Debugger Canvas on a multithreaded application, I’d love to see the thread ID and/or name in the display when it’s an active call stack. It’s a little to easy to get lost in a multithreaded canvas.
• It would be nice to have a timestamp on a bubble. When one canvas is getting reused you can see at a glance which is the most recent chain.
• It would be nice to have a way to remove a whole chain at once.

Please do let the team know your feedback at the DevLabs Debugger Canvas forum.

Business is good and we need YOU! Wintellect is currently seeking senior level technical development resources for both contract and permanent employment for our current client projects. If you want the challenge of keeping up with co-workers like Jeffrey Richter, Jeff Prosise, Keith Rome, or Jeremy Likness, have we got the opportunity of a lifetime. Please have lots of hands on development experience in the following technologies: C#, ASP.NET MVC, WPF, WCF, Silverlight and SQL Server. Experience with HTML5 and jQuery would be ideal also. If you can't tell, it's all cutting edge here at Wintellect so if you like doing the latest technology we'd love to talk with you. Please forward your resume and availability to Barbara Keihm, Director of Human Resources, bkeihm@wintellect.com.

Paraffin 3.6 can be downloaded here: http://www.wintellect.com/CS/files/folders/18310/download.aspx

Dan Gough had an excellent feature request to have Paraffin copy over any manually added namespaces to the .WXS file like the following. Previously, Paraffin ignored them, but no more.

I updated Paraffin to copy over any namespaces added to the Wix element when creating the .PARAFFIN file. If you were having Paraffin inject additional elements with a .ParaffinMold file, now it’s easier than ever to keep your WiX fragments up to date.

When adding custom namespaces, put them before the default xmlns="http://schemas.microsoft.com/wix/2006/wi" as I’ve shown in the snippet above. With LINQ to XML, the xmlns attribute is special and does not show up in the Attributes collection so there’s no way I can sort it with the rest of the values. When generating the output XML file, XDocument always puts the xmlns attribute last. I tried all sorts of tricks to get it placed first but never got them to work.

There’s no trouble if you place your custom namespaces after the default xmlns, but in the .PARAFFIN file they will always appear first so you’ll see more changes when you diff the .WXS and .PARAFFIN file.

Please do let me know if you have feature requests! I considered adding a command line switch to allow adding custom namespaces when creating a .WXS fragment but didn’t think that would be used very much so decided against it. Of course, now that I’ve mentioned this option everyone’s going to ask for it. <grin!>

If you’re not familiar with Paraffin, please read the Zen of Paraffin document in the root directory of the download.

The other day I was asked which extensions for Visual Studio I use so in an effort to save keystrokes, I thought I’d list them here so I can refer people to this list. There’s no way this is a comprehensive list and I do add and remove extensions all the time. However, these are the ones that always stay installed because if they aren’t, I can’t use Visual Studio. By the way, these are all free.

Productivity Power Tools

Want a bunch of features for the next version of Visual Studio today? That’s exactly what Microsoft’s Productivity Power Tools are all about. Once you use the awesome Solution Navigator, you’ll wonder how you ever lived without it. Add in the better Tab Well UI, Quick Find, and all the other enhancements and you’re in Visual Studio heaven. This is the single most important extension available.

NuGet Package Manager

The first time you add an open source package to your solution, you’ll thank your lucky stars for this extension. It’s quick and easy so you can focus on what you need to do instead of the integration. What I find even better than the package manager is that NuGet adds a PowerShell window to Visual Studio. I’m using that constantly these days because the $dte variable exposes the Visual Studio automation model to PowerShell.

VS Color Output

This fine extension adds color-coding to output windows in Visual Studio. Seeing build breaks in red and good builds in green, as well as control over all other output, is something that should have been built into Visual Studio already. The latest version 1.1 update fixes a crashing issue people were reporting.

HTML Spell Checker

I can’t spell at all and this extension keeps me from looking like moron as others look at the comments in my code.

Highlight All Occurrences of a Selected Word

A super simple extension that does exactly what the title says. It’s wonderful when doing presentations to highlight a word and for looking at all uses of a global variable. Note that this extension offers no customizability so you’re stuck with the lime green highlight that does not work so well with you wild kids using dark background themes.

So what extensions can you not live without? I’d love to know what extensions you use so either blog about them or add them to the comments.

Edit: Make sure to read the comments from Shay Levy and Richard on clarifying my mistaken assumptions about how things work in PowerShell. Thanks to Richard & Shay for the clarifications! 

As I’m a command line kind of guy, I look for every opportunity to stay in a PowerShell window at all times. “Why grab the mouse when you don’t have?” to is my motto! The other day I was working on my laptop and was running short of battery power so wanted to switch to the Power Saver plan. A quick search told me POWERCFG.EXE was the command line tool to use.

Hold on there Flash! POWERCFG.EXE with the –S option is the command line way to change power plans, but to specify the plan you must use the GUID of the plan. While I’m a big fan of GUIDs there’s several places where GUIDs are not appropriate: command line tools, URLs, and any other place where end users could see them. Shouldn’t you just be able to set the power plan by name like “Balanced, ” “Power Saver,” or if you are feeling randy, “High Performance?” That’s an oversight that needs to be fixed so below is a PowerShell script, Set-PowerPlan.ps1, that lets you set the power plan at the command line based on the name of the plan instead of an ugly GUID.

The basic idea of the script is to get the list of defined power plans from “POWERCFG.EXE –l” and parse the output with a regular expression looking for the plan name with matching GUID. With the GUID in hand calling “POWERCFG –s <GUID>” flips to the defined plan. The regular expression work was simple, but there was one thing that stumped me.

In all the PowerShell work I’ve done I’ve never needed to capture the output of an old-school command line program like POWERCFG.EXE. It seemed so simple to do something like “$plans = POWERCFG –l” to get the list of plans and parse the output with “$plans –match <some regex>” to pull out the GUID. Little did I know that would definitely not be anything approaching normal. Yet again a PowerShell-ism reached up and dope slap me hard.

Interactively in a PowerShell console window, I ran “$plans = POWERCFG –l” and double-checked that $plans was a string by executing “$plans | Get-Member” as piping to Get-Member will report the type of object. Sure enough I was looking at a System.String. Oddly, when I ran “$plans –match <regex>” it always returned false even though typing “$plans” definitely showed me the complete output of the “POWERCFG –l” and the exact string I was looking for was there.

What totally confused me was running “$plans.Length” as that reported “7” instead of the 364 characters I counted in the string. After a bunch of reading I finally realized that $plans is really a freaking ARRAY of seven lines instead of a complete string. When PowerShell captures the output of a regular command line program as an array of strings. Whenever one is first exposed to PowerShell you invariably are taught about the Get-Member command right at the beginning to figure out the type of an object. When Get-Member lies to you it’s hard to get a clue. It’s things like this that make you understand why so few developers have switched over to PowerShell.

If you want all the output of a regular command line program into an actual string you have two choices. The first is to explicitly type the receiving variable with [string] like the following: “[string]$plans = powercfg -l” The alternative is to gather the regular command output into a variable, but if you need to look across all that output pipe the variable array to Out-String surrounded by parenthesis as in “($plans | Out-String)”.

I’m sure some PowerShell Ninja will jump in here and tell me how I missed the obvious, but I don’t feel I did. Hopefully, this little PowerShell gotcha will help you go down the PowerShell route with more confidence. While PowerShell has some bumps along the way the journey is totally worth it!

So you have an awesome minidump your IT guys grabbed with ProcDump. You’ve followed all the rules and have a Symbol Server and Source Server all set up. You open that dump with Visual Studio and BOOM, none of your indexed sources show up. You pull your hair out trying to get your public build sources appear but they never do and it’s just “SRCSRV: The module ‘<<path to the exe file>>’ does not contain source server information.” for everything in the Output window.

Fortunately, a smiling bald guy, Andy Hopper, figured out how to make it all work. Turns out when opening a minidump, the “managed debugging engine tries to verify that each source server enabled assembly is running as a fully trusted assembly from the CLR’s perspective.” Ahh, nothing like security to turn off a feature. The great news is that you can tell the managed debugging engine to stop doing the checks so the Source Server works with the managed minidumps. It’s as simple as setting a registry key. Swipe the registry script below and you are good to go.

All credit to Andy Hopper on this one!