Wintellog

The Task: Async and Await in a Windows Runtime World

C#er : IMage — Tue, 15 May 2012 03:43:01 GMT

In my last blog post , I covered how to wrap your arms around the Task class and its relationship to the new async and await keywords. I mentioned that the post was focused on the .NET Framework only because the Windows Runtime handles these operations differently. In this post, I’ll cover what those differences are. Task is a Task is a Task First, in the Windows Runtime, a Task is a Task … is a Task . You can write your code to return a Task or Task<T> in your Windows 8 Metro applications....(read more)

The Task: Events, Asynchronous Calls, Async and Await

C#er : IMage — Fri, 11 May 2012 17:42:02 GMT

Almost any software application today will likely contain a long-running process. “Long-running” may be a relative term but in the Windows Runtime it is specifically anything that could take longer than 50ms to execute. That’s a fairly small window, and it means those operations will need to run concurrently to the main application thread. Concurrency is important in both client applications (to keep from blocking the UI) and server applications (to accommodate multiple simultaneous requests). The...(read more)

Sample Applications from Designing Silverlight Business Applications

C#er : IMage — Sun, 15 Apr 2012 06:42:00 GMT

I've received a few emails regarding the book that the code files are not available from the publisher website. I've spoken with the publisher about this and they are working to correct it, but I wanted to provide a link for those of you who have been patiently waiting. As a backup to the main website, I've posted all of the sample applications online to SkyDrive and you can download them by clicking on this link . I appreciate you patience and hope you will take the time to post a review on the...(read more)

CodeStock 2012

C#er : IMage — Mon, 09 Apr 2012 05:34:01 GMT

Thanks for everyone's support and votes. I have been selected to present two sessions at CodeStock 2012. Per the CodeStock website: CodeStock is a two day event for technology and information exchange. Created by the community, for the community — this is not an industry trade show pushing the latest in marketing as technology, but a gathering of working professionals sharing knowledge and experience. This is always a great conference. I have the added bonus of getting close to the corporate...(read more)

Designing Silverlight Business Applications Officially Released

C#er : IMage — Thu, 05 Apr 2012 09:24:04 GMT

In June of 2011 I started the journey of writing a Silverlight book. The Silverlight team was about to release version 5 with an incredible set of new features that would revolutionize how it can be used in the enterprise. I knew there were already a number of books available to use a reference for fundamentals and controls, so I wanted to dig deeper and hit the topics I was challenged with in my job as a consultant as well as those questions that continually seem to surface on blogs and forums....(read more)

The Top 10 Features Windows 8 Metro Developers Will Love

C#er : IMage — Tue, 03 Apr 2012 10:02:02 GMT

Windows 8 Metro is a new platform for developing applications that are tailored to the devices on which they run. These devices may include traditional desktops and laptops as well as the new tablet and slate form factors. In this article I cover the top ten features developers will love about the new development environment. This is part of my work on the upcoming book, Building Windows 8 Metro Applications with XAML and C#. Read the full article online at InformIT. (c) 2011-2012 Jeremy Likness...(read more)

Using NuGet PowerShell to Replace Missing Macros in Dev 11

jrobbins — Fri, 30 Mar 2012 20:55:13 GMT

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
 

.NET and Metro: The Windows Runtime and the CLR on Windows 8

C#er : IMage — Thu, 29 Mar 2012 16:53:00 GMT

Many developers tend to look at Windows 8 as a completely new platform and even question whether it heralded the imminent demise of managed code. After spending many months digging into the Windows Runtime (WinRT), Metro style or “tailored” applications, and exploring how they related to the .NET Framework, I’ve come to the conclusion that the two work very closely together and in fact are engineered to integrate. That means good news for managed developers. The .NET Framework 4.5 is very much “Metro-aware”...(read more)

Wintellect T-shirt Design – Help us pick our new design!

bvananda — Mon, 26 Mar 2012 18:32:00 GMT

It’s time for a new Wintellect t-shirt and we want your help. Our Wintellectuals have been hard at work creating designs that we hope all of you will want to wear! We have narrowed down the top 2 designs internally and we want to ask each of you for your help in selecting the new Wintellect t-shirt.

Vote for the design you like by simply placing “Design 1” or “Design 2” into the comments section of this post and by including a short note on what you like most about the design. We will chose the top 5 most inspirational comments and the winners will receive one of Wintellect’s new t-shirts and a $10 Starbucks gift card.

The voting starts NOW and runs through this Friday, March 30th. The 5 winners will be announced during the week of April 1^st. Thanks for all of your feedback! Vote for the top design TODAY!

Design 1:

Design 2:

Jounce MVVM WCF RIA Printing and More Example

C#er : IMage — Thu, 22 Mar 2012 18:52:05 GMT

I finally managed to update and upload my To-Do List Reference Application . This is a Silverlight 5 application based on my Jounce framework that demonstrates a number of different features. I built it as part of my book, Designing Silverlight Business Applications . There are several chapters devoted specifically to the construction of this example application. It is a demonstration application, so while it contains a lot of different components designed to illustrate various points, it's not intended...(read more)

Get Your Next Job Here!!

jrobbins — Fri, 16 Mar 2012 20:34:22 GMT

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.

Understanding the Portable Library by Chasing ICommand (3 of 3)

C#er : IMage — Wed, 14 Mar 2012 04:16:04 GMT

Part 1: Creating the Portable Library (this post) Part 2: Portability in Silverlight and WPF: a Tale of Type Forwarders Part 3: Portability in Metro: A CLR and WinRT Love Affair (this post) Portability in Metro: A CLR and WinRT Love Affair In this series we’ve covered the portable library and reviewed how it allows you to create assemblies that can be shared without recompilation across multiple platforms. You created a portable assembly with a view model and a command in it, then successfully integrated...(read more)

Updated PowerShell Scripts to Manage Symbol Server and Source Server Settings

jrobbins — Wed, 14 Mar 2012 00:28:47 GMT

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.
 

Understanding the Portable Library by Chasing ICommand (2 of 3)

C#er : IMage — Fri, 09 Mar 2012 14:20:05 GMT

Part 1: Creating the Portable Library Part 2: Portability in Silverlight and WPF: a Tale of Type Forwarders (this post) Part 3: Portability in Metro: A CLR and WinRT Love Affair Portability in Silverlight and WPF: a Tale of Type Forwarders In the last post, I walked through creating a portable assembly that will target Silverlight 4.0 and above, .NET Framework 4.5, and Windows 8 Metro. In the assembly were a few classes that handled commands and property change notification for a simple view model....(read more)

What’s New in SOS for .NET 4.5?

jrobbins — Thu, 08 Mar 2012 21:27:57 GMT

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!

Understanding the Portable Library by Chasing ICommand (1 of 3)

C#er : IMage — Thu, 08 Mar 2012 17:45:01 GMT

Part 1: Creating the Portable Library (this post) Part 2: Portability in Silverlight and WPF: a Tale of Type Forwarders Part 3: Portability in Metro: A CLR and WinRT Love Affair The portable library tools have been available for several months now. The goal for this add-in to Visual Studio 2010 was to enable you to create special portable assemblies that can run on various platforms, ranging from XBox and Windows Phone 7 to various versions of the .NET Framework and Windows 8, without having to recompile...(read more)

Cool Dev 11 Trick: Diff Random Files Easily

jrobbins — Thu, 08 Mar 2012 01:56:39 GMT

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.

Windows 8 Icons: Segoe UI Symbol

C#er : IMage — Tue, 06 Mar 2012 07:28:01 GMT

Here’s a quick and easy tip for developing Windows 8 Metro applications. Are you looking for decent icons to use in your Application Bar ? Windows 8 makes it incredibly easy by using the built-in Segoe UI Symbol font. There are tons of icons embedded in the font that are perfect for using in your applications. Take a look at the following XAML snippet from the Microsoft quick start for adding an app bar : < StackPanel Orientation ="Vertical" Margin ="0,14,0,5" Grid . Column ="1" > < Button...(read more)

Using the New Caller Information Attributes for Reliable Property Change Notifications

jgarland — Mon, 05 Mar 2012 03:03:13 GMT

As anyone who has implemented the INotifyPropertyChanged interface knows, the fact that the PropertyChangedEventArgs takes a property name as a string means that you are one fat-fingered mistake away from a bug that can sometimes be difficult to track down. If the property name supplied in the string doesn’t match the actual property name, the data binding (or other operations) that relies on this interface doesn’t work properly.

        1: public Int32 MyProperty

       2: {

       3:     get { return _myProperty; }

       4:     set

       5:     {

       6:         if (_myProperty != value)

       7:         {

       8:             _myProperty = value;

       9:             OnPropertyChanged("MyProperty");

      10:         }

      11:     }

      12: }

Lambda expressions and Expression Trees in .Net 3 brought a solution to the problem, where the compile-time checking could help ensure that a correct value was provided. I blogged about this back in 2010 (http://blog.dotnetgator.com/2010/06/21/finding-binding-trouble/), and even cited my (then-future) coworker Jeremy Likness’s treatment of the same topic (http://csharperimage.jeremylikness.com/2010/06/tips-and-tricks-for-inotifypropertychan.html).

       1: public Int32 MyProperty

       2: {

       3:     get { return _myProperty; }

       4:     set

       5:     {

       6:         if (_myProperty != value)

       7:         {

       8:             _myProperty = value;

       9:             OnPropertyChanged(() => MyProperty);

      10:         }

      11:     }

      12: }

Now there’s a new feature in .Net 4.5 that provides yet another opportunity to ensure that INotifyPropertyChanged is implemented correctly – possibly in a simpler fashion than ever before, and with better performance than the Expression Tree/Lambda expression approach.

.Net 4.5 includes 3 new “Caller Information” attributes – CallerFilePathAttribute, CallerLineNumberAttribute, and CallerMemberNameAttribute. These three attributes are scoped to individual method parameters, and when used, they apply the indicated value from the CALLING METHOD to the called method’s attributed parameter at run time. In our case, we’re interested in the CallerMemberName attribute, which we can use to automatically retrieve the property that is trying to raise the property change notification:

       1: private void OnPropertyChanged([CallerMemberName] String caller = null)

       2: {

       3:     var handler = PropertyChanged;

       4:     if (handler != null)

       5:     {

       6:         handler(this, new PropertyChangedEventArgs(caller));

       7:     }

       8: }

Note that the Caller Information attributes require a default value be supplied.

This reduces the overhead of a property in the class that provides this method to the following:

       1: public Int32 MyProperty

       2: {

       3:     get { return _myProperty; }

       4:     set

       5:     {

       6:         if (_myProperty != value)

       7:         {

       8:             _myProperty = value;

       9:             OnPropertyChanged();

      10:         }

      11:     }

      12: }

Of course, one important question is how does this method perform in comparison to either just providing a string, or using the Lambda/Expression Tree approach? In my tests with iterations of between 1,000-500,000 property changes I saw between ~10-30% performance improvement over the Lambda/Expression Tree approach, and performance between ~20-30% lower than using a directly supplied string.

Note that the latest version of the MSDN documentation illustrating the implementation of the INotifyPropertyChanged interface (as of this writing) show the use of the CallerMemberName attribute - http://msdn.microsoft.com/en-us/library/ms229614(v=vs.110).aspx.

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

jrobbins — Sat, 03 Mar 2012 20:22:45 GMT

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

jrobbins — Wed, 29 Feb 2012 17:08:09 GMT

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.

Windows 8 Consumer Preview 101

C#er : IMage — Wed, 29 Feb 2012 09:27:04 GMT

It’s finally here! Unless you’ve been hiding under a rock, you have heard the buzz around the Windows 8 Consumer Preview. If you haven’t had the opportunity to grab it and install it, I suggest you browser over to this link now and download your copy! There are many exciting new features, and this post will guide you through a few of them. It is a Beta After All There has been much buzz around whether or not the name “Consumer Preview” means it is not a beta and therefore the final release will be...(read more)

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

jrobbins — Fri, 24 Feb 2012 19:10:37 GMT

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!

What are YOU Looking for in the Consumer Preview?

C#er : IMage — Fri, 24 Feb 2012 10:06:00 GMT

It seems there is quite a bit of anticipation surrounding the imminent release of the Windows 8 Consumer Preview. I've read the speculation about what it will actually include, or not include, and if this release really means anything in the larger scheme of things. The release will coincide with the Mobile World Congress . What I find interesting is that the same week, thousands of Microsoft MVP awardees will descend on Bellevue, Washington (close to the campus in Redmond) for the Global MVP Summit...(read more)

Programmatically uninstalling Silverlight Out-Of-Browser Application

sloscialo — Tue, 21 Feb 2012 22:41:50 GMT

Every once in a while there comes a need to provide a mechanism to uninstall your application programmatically. For Silverlight Out-Of-Browser applications , there seemed to be no way to accomplish it. Fortunately, there’s a work-around that trusted OOB applications running in Windows can use.

Silverlight OOB applications are launched via the “sllauncher.exe” command. And if you open the properties on an OOB shortcut, you will see a target textbox with something like:

"C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe" 2205248641.localhost

Of course, “sllauncher.exe” has some command-line parameters and settings we can use to install and uninstall Silverlight OOB applications. Since trusted Silverlight OOB applications can access COM Automation, we can run the “sllauncher.exe” application from within Silverlight. The catch is that we’re not sure exactly where the program is located.

There may be exceptions, but as a general rule “sllauncher.exe” is located in 1 of 2 places:

on 64-bit machines : C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe

on 32-bit machines : C:\Program Files\Microsoft Silverlight\sllauncher.exe

However, there’s no way to know which OS type you’re running on. So we need to check for the existence of these folders. Since they’re out of the sandbox, we have to resort to COM Automation to determine if they exist.

   1: string launcherPath = string.Empty;

   2: using (dynamic shell = AutomationFactory.CreateObject("Shell.Application"))

   3: {

   4:     string launcher64 = @"C:\Program Files (x86)\Microsoft Silverlight";

   5:     string launcher32 = @"C:\Program Files\Microsoft Silverlight";

6:

   7:     dynamic folder64 = shell.NameSpace(launcher64);

   8:     if (folder64 != null) launcherPath = launcher64;

9:

  10:     dynamic folder32 = shell.NameSpace(launcher32);

  11:     if (folder32 != null) launcherPath = launcher32;

  12: }

To silently uninstall a Silverlight OOB application using “sllauncher.exe” you’d normally type something like:

sllauncher.exe /uninstall /origin:[origin location]

Once again, using COM Automation, we can have our application run the command.

   1: using (dynamic shell = AutomationFactory.CreateObject("WScript.Shell"))

   2: {

   3:     string origin = Application.Current.Host.Source.OriginalString;

   4:     shell.Run(string.Format(@"{0}/sllauncher.exe /uninstall /origin:""{1}""", launcherPath, origin));

   5: }

That’s really all there is to it (other than adding in some error checking, of course).