Today my DotNet Pretty articles were featured on @coding4fun by Greg Duncan and one of the comments by Niner bc3tech (@bc3tech) requested that I share this solution on Chocolatey. I decided that this was a good idea and decided to share my experience Smile.

Creating a Chocolatey Account

Creating the Chocolatey account was as simple as filling a couple of common fields at https://chocolatey.org/account/Register.


In the registration mail you are given a link to Rules to be observed before publishing packages which mentions that you can host your packages with MyGet


Creating a MyGet Account

Heading over to MyGet I saw that they had a Free subscription


But they also have an offer for MVP's, ASPInsiders, Windows Azure Insiders and ALM Rangers Smile. Fitting into 2 of these categories now I decided to head over to https://www.myget.org/mvp and request a NFR license Open-mouthed smile. The extra features available on this subscription made it perfect for my community project (and ones to follow Smile). In no time I had my DotNet Pretty Package Feed up.

MyGet Build Services

The DotNet Pretty project is currently hosted out on GitHub and so I decided that I'll try out MyGet's build services which is now in preview. This was as simple as clicking on BUILD SERVICES from the menu and then on Add build sources and then from GitHub.


this poped open the Link build source dialog where I selected the DotNet Pretty project from the list and clicked Add.


From here I clicked Build and in no time the build completed


2014-10-27_18-54-50 and I had a package hosted in MyGet



Updating GitHub project to show MyGet build status

From the build services page I was able to click on copy markdown


which gave me the markdown that I could insert into the readme.md file which I did with my new favorite Markdown editor MarkdownPad 2


A quick commit added this status to the public project on GitHub


Pushing the packaged to Chocolatey

The next thing I needed to do was add a new package source to my MyGet package feed Chocolatey. I went over to the Package Sources menu and clicked on Add package source and the NuGet feed.


The next bit was very simple, I simple clicked on Presets and then Chocolatey


This then went ahead and filled in the Name and Source for me


All that was left to do was provide my Chocolatey which was my Username, Password and API Key. I also filled in some of the extra meta data for my source


Next I headed over to build services again and clicked on Push upstream


this presented a window like below


where I just clicked on Push


And received the message saying they on it Open-mouthed smile. Headed back over to Chocolatey and my package was in the list


Installing Chocolatey "Client"

On the machine I'm using I didn't have Chocolatey installed so opened up a PowerShell Command Window as Administrator (just for in case Smile) and ran the command

iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

Installing my package

To test if my package was installer I ran the command below

choco install DotNetPretty -Pre 

which confirmed that my package now now been installed


At this point my Chocolatey package "installs" by dropping the package contents in the Chocolatey folder


In a later post I will share how to configure the installation logic for a Chocolatey script.

Update: The post can be found here (Configuring a Chocolatey Install).


So yesterday I posted Pushing a new project to Chocolatey and I said I would create another post showing how to configure how the Chocolatey install runs and this is that post Smile with tongue out.


The first (only really) step to do this is creating a ChocolateyInstall.ps1 script. From looking at other packages I saw that there was a file like this in a tools folder so I created one for myself in my DotNet Pretty project


and set the Build Action to Content and Copy to Output Directory to Copy Always


The contents of the script was as below

[string]$ScriptDir = Split-Path $MyInvocation.MyCommand.Path -Parent
[string]$copyTo = "$([System.Environment]::GetFolderPath("mydocuments"))\Visual Studio 2013\Visualizers"
[string]$mainAssemblyPath = "$ScriptDir\..\..\lib\net45\*.*"
[string]$binDependenciesAssemblyPath = "$ScriptDir\..\binDependencies\*.*"
if (!(Test-Path -LiteralPath $copyTo))
New-Item -Path $copyTo -ItemType directory
Copy-Item -Path "$mainAssemblyPath" -Destination "$copyTo" -Force
Copy-Item -Path "$binDependenciesAssemblyPath" -Destination "$copyTo" -Force

Basically doing the exact same thing as what I was doing with the DEBUG post build event in the project settings

I checked that in (over a couple of commits because I didn't get it right the first time Smile with tongue out). MyGet picked up the new commit and performed a build for me. Instead of waiting for my hourly push of packages to Chocolatey from MyGet I just pushed the package as I did in the previous post. I then ran the Chocolatey install for my package

choco install dotnetpretty -pre

and then navigated to the Visualizers folder and my new assemblies were there Smile


If you have any feedback or a better way to perform this install do let me know Open-mouthed smile


In my last post (Introduction to DotNet Pretty) I mentioned that I would be added more visualizers to DotNet Pretty soon Smile. Today I finally managed to get around to that and added some visualizers for TFS Work Items.

3 new visualizers were added 2 debugger display visualizers and 1 debugger visualizer. The first is for Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemType and just displays the Name of the Work Item Type


The next  one added was for Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem and that displays the Status, Id and Title of a work item which is awesome for viewing the results of a query during debugging Smile.


Now having the above is very useful but drilling down into fields was a nightmare so I decided to create a nice visualizer for Work Item which would show you the work item on a form as it would be inside Visual Studio. You simple click the little arrow next to the value and then click on View Work Item


and then you will notice that your life has just been changed Smile. Any links you click on from within this window will open in the web access and not in another dialog as you might expect.


This work item will show as it is at the current point in the code to the best of the visualizers abilities Smile, in the case above I altered the title just before I opened the visualizer and it kept it's new value as expected Open-mouthed smile.


I have tested this on both On Premise TFS and Online with VSO. The On Premise version did give an issue about COM which I'm hoping is just an issue on my machine/instance but will investigate anyway


I know this is going to help me speed working with the TFS API and I'm hoping it's useful to others as well Open-mouthed smile.


Some Background on why

Another thing that come out of last weeks training was Visual Studio Debuggers. This lead to me finding the coolest visualizer ever called TPL Dataflow Debugger Visualizer which allows you to easily visualize your TPL Dataflow

TPL DataFlow Debugger Visualizer

Because I found this awesome visualizer I decided that everything while debugging could be awesome if there were more of these so I have created a GitHub project called DotNet Pretty where I plan on creating many visualizers to really try light up the debugging experience.

What is DebuggerDisplayAttribute?

In case you don't know DebuggerDisplayAttribute is used when you want to have a "pretty" representation of the properties in your class when seeing it in the debugger.

What MSDN says

Debugger display attributes allow the developer of the type, who specifies and best understands the runtime behavior of that type, to also specify what that type will look like when it is displayed in a debugger.

How do you implement them

You simple place the DebuggerDisplay Attribute on a class like below


When the break point is hit instead of you seeing the objects ToString() implementation of the method as below


which of course you could override to show a nice message if you wanted to, you will get something like below


It doesn't seem like such a big deal with 1 object but think of how easy it would be to know stuff about objects when they in a list if they each implemented this attribute. Now obviously to use the attribute like this you need to own the object so you can add the attribute and release it.

DotNet Pretty's first contribution

The first contribution to DotNet Pretty is one that was used in the training which allows you to use the DebuggerDisplay Attribute in a different way.


This time you specify the target in the attribute like below


As you can see this is just floating in a random .cs file so it doesn't have to be placed anywhere specific in the code.

What it looks like

This time instead of seeing the ToString() method


You will see


Deploying Visualizers

Now obviously Visual Studio can't do magic to find out where the visualizers are across your whole machine so to get your custom visualizers to you work you simple need to drop the output assemblies in the path C:\Users\[username]\Documents\[Visual Studio Version]\Visualizers which in my case is C:\Users\GordonB\Documents\Visual Studio 2013\Visualizers.


How is the TDL Dataflow visualizer done?

In short the TPL Dataflow visualizer uses the DebuggerVisualizerAttribute which looks something like below


I will do a in detail post on DebuggerVisualizer Attribute when I add one to DotNet Pretty. For now though you can browse the source code of the TPL Dataflow Debugger Visualizer on CodePlex.

So what's the plan?

My plan at the moment is to find the .net types that I use most and implement visualizers for them. I'm planning on trying to get some nice ones in for TFS objects like Work Items. I'm hoping that others will use this library of visualizers and fork the code and help grow it.