John Robbins' Blog

Using NuGet PowerShell to Replace Missing Macros in Dev 11

2012-03-30T20:55:13Z

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.

 Get-Interface $dte.Debugger.Breakpoints[0] ([ENVDTE80.Breakpoint2])
 

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.

 TOPIC
    about_WintellectVSCmdlets
    
SHORT DESCRIPTION
    Provides missing functionality, especially around debugging, to Visual Studio 2010 and Dev 11.
           
LONG DESCRIPTION
    This describes the basic commands included in the WintellectVSCmdlets module. With Dev 11 not offering
    macros, simple extensions require installing an SDK and debugging the extensions with a second instance
    of the IDE. In all, it makes for a very poor experience when you want to do simple customization of the 
    the development environment.
    
    These macros, which are very useful for debugging, demostrate that the NuGet Package Console is 
    sufficient for many of your customization needs. Most of these cmdlets are ports of VB.NET macros that 
    John Robbins has shown on his blog and books.
    
    All cmdlets work with both Visual Studio 2010 and Dev 11.
    
    Note that these cmdlets support C#, VB, and native C++. They probably support more but those were
    all the languages tested.
 
    If you have any questions, suggestions, or bug reports, please contact John at john@wintellect.com.
                 
    The following Wintellect VS cmdlets are included.
 
        Cmdlet                                            Description
        ------------------                                ----------------------------------------------
        Add-BreakpointsOnAllDocMethods                  Sets breakpoints on methods in the current code document. This
                                                        is very useful in .NET languages as the debugger expression 
                                                        evaluator does not support that.
                                                        
        Remove-BreakpointsOnAllDocMethods               Removes all the breakpoints set with Add-BreakpointsOnAllDocMethods.
                                                        This cmdlet will not remove any of your breakpoints.
        
        Add-InterestingThreadFilterToBreakpoints        Adds the filter "ThreadName==InterestingThread" to all breakpoints to
                                                        make it easier to debug through a single transaction.
                                                        
        Remove-InterestingThreadFilterFromBreakpoints   Removes the "ThreadName==InterestingThread" filter applied with
                                                        Add-InterestingThreadFilterToBreakpoints.
 
        Disable-NonActiveThreads                        Freezes all but the active thread so you can single step to the end
                                                        of a method without dramatically bouncing to another thread when you 
                                                        least expect it.
                                                        
        Resume-NonActiveThreads                         Thaws all threads previously frozen with Disable-NonActiveThreads.
 
        Get-Breakpoints                                 Returns the latest version of the IBreakpoints derived list.
        
        Get-Threads                                     Returns all the threads.
        
        Invoke-NamedParameter                           A wonderful cmdlet that lets you easily call methods with many
                                                        optional parameters. Full credit to Jason Archer for this cmdlet.
        
        Invoke-WinDBG                                   VS/Dev 11 have ease of use, where WinDBG (with SOS + SOSEX) have 
                                                        tons of power to tell you what's going on in your application. This
                                                        cmdlet starts WinDBG on the process you're currently debugging in the
                                                        IDE so you can have the best of both worlds.
                                                        
        Open-LastIntelliTraceRecording                  When you stop debugging, your current IntelliTrace log disappears. This
                                                        cmdlet fixes that by opening the last log you produced so you can post-mortem
                                                        look at your debugging session.
 
SEE ALSO
    Online help and updates: http://www.wintellect.com/CS/blogs/jrobbins/default.aspx
    Add-BreakpointsOnAllDocMethods
    Remove-BreakpointsOnAllDocMethods
    Add-InterestingThreadFilterToBreakpoints
    Remove-InterestingThreadFilterFromBreakpoints
    Disable-NonActiveThreads
    Resume-NonActiveThreads
    Get-Breakpoints
    Get-Threads
    Invoke-NamedParameter
    Invoke-WinDBG
    Open-LastIntelliTraceRecording
 

Get Your Next Job Here!!

2012-03-16T20:34:22Z

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.

Updated PowerShell Scripts to Manage Symbol Server and Source Server Settings

2012-03-14T00:28:47Z

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:

 (get-module WintellectPowerShell).ExportedFunctions.Keys | sort | foreach-object { Get-Help detailed $_}
 

I thought that was pretty cool!

 NAME
    Expand-ZipFile
SYNOPSIS
    Expands a .ZIP file to the specified directory.
SYNTAX
    Expand-ZipFile [-ZipFile] <String> [-Destination] <String> [<CommonParameters>]
DESCRIPTION
    Using no external ZIP utilities, expands a .ZIP file to a specified directory.
PARAMETERS
    -ZipFile <String>
        The .ZIP file to expand.
    -Destination <String>
        The output directory for the ZipFile. If this directory does not exist, it will
        be created.
 
NAME
    Get-SourceServer
SYNOPSIS
    Returns a hashtable of the current source server settings..
SYNTAX
    Get-SourceServer [<CommonParameters>]
DESCRIPTION
    Returns a hashtable with the current source server directories settings
    for VS 2010, Dev 11 Beta, and the _NT_SOURCE_PATH enviroment variable used 
    by WinDBG.
 
NAME
    Get-SourceServerFiles
SYNOPSIS
    Prepopulate your symbol cache with all your Source Server extracted source 
    code.
SYNTAX
    Get-SourceServerFiles [-CacheDirectory] <String> [[-SrcTool] <String>] [<CommonParameters>]
DESCRIPTION
    Recurses the specified symbol cache directory for PDB files with Source Server
    sections and extracts the source code. This script is a simple wrapper around 
    SRCTOOl.EXE from the Debugging Tools for Windows (AKA WinDBG). If WinDBG is in 
    the PATH this script will find SRCTOOL.EXE. If WinDBG is not in your path, use
    the SrcTool parameter to specify the complete path to the tool.
PARAMETERS
    -CacheDirectory <String>
        The required cache directory for the local machine.
    -SrcTool <String>
        The optional parameter to specify where SRCTOOL.EXE resides.
 
NAME
    Get-SymbolServer
SYNOPSIS
    Returns a hashtable of the current symbol server settings.
SYNTAX
    Get-SymbolServer [<CommonParameters>]
DESCRIPTION
    Returns a hashtable with the current source server directories settings
    for VS 2010, Dev 11 Beta, and the _NT_SYMBOL_PATH enviroment variable.
 
NAME
    Get-SysinternalsSuite
SYNOPSIS
    Gets all the wonderful Sysinternals tools
SYNTAX
    Get-SysinternalsSuite [-Extract] <String> [[-Save] <String>] [<CommonParameters>]
DESCRIPTION
    Downloads and extracts the Sysinternal tools to the directory you specify.
PARAMETERS
    -Extract <String>
        The directory where you want to extract the Sysinternal tools.
    -Save <String>
        The default is to download the SysinternalsSuite.zip file and remove it after
        extracting the contents. If you want to keep the file, specify the save 
        directory with this parameter.
 
NAME
    Get-Uptime
SYNOPSIS
    Returns how long a computer has been running.
SYNTAX
    Get-Uptime [[-computerName] <String>] [<CommonParameters>]
DESCRIPTION
    Returns the TimeSpan for how long a computer is running. If you'd like it 
    formatted you can use "Get-Uptime -f {0}"
PARAMETERS
    -computerName <String>
 
NAME
    Set-SourceServer
SYNOPSIS
    Sets the source server directory.
SYNTAX
    Set-SourceServer [-Directory] <String> [<CommonParameters>]
DESCRIPTION
    Sets the source server cache directory for VS 2010, Dev 11 Beta, and WinDBG 
    through the _NT_SOURCE_PATH environment variable to all reference the same 
    location. This ensures you only download the file once no matter which 
    debugger you use. Because this cmdlet sets an environment variable you 
    need to log off to ensure it's properly set.
PARAMETERS
    -Directory <String>
        The directory to use. If the directory does not exist, it will be created.
 
NAME
    Set-SymbolServer
SYNOPSIS
    Sets up a computer to use a symbol server.
SYNTAX
    Set-SymbolServer [-Internal] [-Public] [[-CacheDirectory] <String>] [[-SymbolServers] <String[]>] [-WhatIf] [-Confi
    rm] [<CommonParameters>]
DESCRIPTION
    Sets up both the _NT_SYMBOL_PATH environment variable as well as Visual Studio 
    2010 and Dev 11 Beta (if installed) to use a common symbol cache directory as 
    well as common symbol servers.
PARAMETERS
    -Internal [<SwitchParameter>]
        Sets the symbol server to use to http://SymWeb. Visual Studio will not use 
        the public symbol servers. This will turn off the .NET Framework Source 
        Stepping. This switch is intended for internal Microsoft use only.
        You must specify either -Internal or -Public to the script.
    -Public [<SwitchParameter>]
        Sets the symbol server to use as the two public symbol servers from Microsoft. 
        All the appropriate settings are configured to properly have .NET Reference 
        Source stepping working.
    -CacheDirectory <String>
        Defaults to C:\SYMBOLS\PUBLIC\MicrosoftPublicSymbols for -Public and 
        C:\SYMBOLS\INTERNAL for -Internal.
    -SymbolServers <String[]>
        A string array of additional symbol servers to use. If -Internal is set, these 
        additional symbol servers will appear after HTTP://SYMWEB. If -Public is 
        set, these symbol servers will appear after the public symbol servers so both
        the environment variable and Visual Studio have the same search order.
 

What’s New in SOS for .NET 4.5?

2012-03-08T21:27:57Z

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.

 >0:000 !dumpheap stat
. . .
000007feefedadd8    21567      2616488 System.Object[]
000007feeff34198   336164      8067936 System.Int32
Total 509034 objects
 
>0:000 !dumpheap stat live
. . .
000007feefedadd8      135       285048 System.Object[]
000007feeff2d8f0    19703       472872 System.WeakReference
Total 22711 objects
 
>0:000 !dumpheap stat dead
. . .
000007feefedadd8    21432      2331440 System.Object[]
000007feeff34198   336158      8067792 System.Int32
Total 486286 objects
 

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.

 00000000002fdca0 000007feefda060f [DEFAULT] [hasThis] Object System.Delegate.DynamicInvokeImpl(SZArray Object) (C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll)
 
PARAMETERS:
  + (Error 0x80131304 retrieving parameter 'this')
  + (Error 0x80131304 retrieving parameter 'args')
 
LOCALS:
  + (Error 0x80004005 retrieving local variable 'local_0')
  + (Error 0x80004005 retrieving local variable 'local_1')
 

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!

Cool Dev 11 Trick: Diff Random Files Easily

2012-03-08T01:56:39Z

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

 Tools.DiffFiles c:\test\a.txt c:\test\b.txt
 

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:

 devenv /diff c:\foo\x.txt c:\bar\y.txt
 

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.

Fixing Stuck/Hung Build in TFS Preview and Dev 11 Beta Build Server

2012-03-03T20:22:45Z

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.

Initial Thoughts After Using the Dev 11 Beta for Two Weeks

2012-02-29T17:08:09Z

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.

Going to the MVP Summit (or in Seattle)? We’d Love to Meetup!

2012-02-24T19:10:37Z

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!

Vote to Treat TFS as an Enterprise Symbol Server

2012-02-15T22:05:09Z

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!

Debugger Canvas 1.1 is Released

2012-01-31T20:48:19Z

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.

Wintellect is Hiring!!

2012-01-24T06:33:18Z

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–Now Keeping Custom Added Namespaces

2012-01-19T23:44:35Z

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.

 <?xml version="1.0" encoding="utf-8"?>
<Wix xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
     xmlns="http://schemas.microsoft.com/wix/2006/wi">
 

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.

Visual Studio 2010 Extensions Recommendations

2012-01-16T18:31:15Z

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.

Setting the Power Plan with PowerShell

2012-01-15T07:54:00Z

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!

Set-PowerPlan.PS1
 #requires -version 2.0
 
# (c) 2012 by John Robbins\Wintellect
 
<#.SYNOPSIS
Sets the current power plan.
.DESCRIPTION
The POWERCFG.EXE utility requires GUIDS when changing a power plan instead of
the name of the plan. That's highly inconvenient so this simple script allows 
you to use common sense names like "Balanced" or "Power Saver" instead.
 
To get the list of power plans on your computer execute 'powercfg -l'
.PARAMETER Plan
The name of the power plan to use.
.EXAMPLE 
Set-PowerPlan -Plan Balanced
Sets the power plan to the Balanced plan, the recommnded Microsoft plan.
.EXAMPLE 
Set-PowerPlan "Power Saver"
Sets the power plan to the Power Saver plan to reduce battery usage.
.LINK
http://www.wintellect.com/CS/blogs/jrobbins/archive/tags/PowerShell/default.aspx
#>
 
param ($Plan = $(throw 'You must specify the power plan, use "powercfg -l" for the plan names' ))
 
Set-StrictMode -Version Latest
 
# Get the list of plans on the current machine.
$planList = powercfg.exe -l
 
# The regular expression to pull out the GUID for the specified plan.
$planRegEx = "(?<PlanGUID>[A-Fa-f0-9]{8}-(?:[A-Fa-f0-9]{4}\-){3}[A-Fa-f0-9]{12})" + ("(?:\s+\({0}\))" -f $Plan)
 
# If the plan appears in the list...
if ( ($planList | Out-String) -match $planRegEx )
{
    # Pull out the matching GUID and capture both stdout and stderr.
    $result = powercfg -s $matches["PlanGUID"] 2>&1
    
    # If there were any problems, show the error.
    if ( $LASTEXITCODE -ne 0)
    {
        $result
    }
}
else
{
    Write-Error ("The requested power scheme '{0}' does not exist on this machine" -f $Plan) 
}
 

Want Source Server to Work with Managed Minidumps in Visual Studio? Here’s How!

2012-01-06T18:29:23Z

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!

 Windows Registry Editor Version 5.00
 
; Enables Source Server support when opening up managed minidumps in Visual Studio.
; All credit to Andy Hopper!
; http://smilingbaldguy.wordpress.com/2012/01/06/managed-minidump-debugging-now-with-source-server-support/
; If you're on a 32-bit machine (and why would you be?) remove Wow6432Node.
;
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\AD7Metrics\Engine\{00000000-0000-0000-0000-000000000000}]
"RequireFullTrustForSourceServer"=dword:00000000
 