0 Comments

Inspiration

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.

2014-10-27_18-28-35

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

2014-10-27_18-34-55

Creating a MyGet Account

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

2014-10-27_18-37-06

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.

2014-10-27_18-47-01

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

2014-10-27_18-48-37

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

2014-10-27_18-52-16

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

 

2014-10-27_18-55-56

Updating GitHub project to show MyGet build status

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

2014-10-27_18-58-09

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

2014-10-27_18-59-29

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

2014-10-27_19-02-04

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.

2014-10-27_19-24-12

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

2014-10-27_19-25-49

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

2014-10-27_19-26-42

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

2014-10-27_19-29-39

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

2014-10-27_19-30-34

this presented a window like below

2014-10-27_19-32-34

where I just clicked on Push

2014-10-27_19-33-11

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

2014-10-27_19-34-27

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

2014-10-27_19-39-35

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

2014-10-27_19-46-252014-10-27_19-47-17

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).

0 Comments

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.

ChocolateyInstall.ps1

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

2014-10-28_08-18-26

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

2014-10-28_08-18-52

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

2014-10-28_08-24-11 

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

0 Comments

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

image

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.

image

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

image 

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.

image

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.

image

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

image

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.

6 Comments

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

2014-07-17_21-10-51

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

image

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

image

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.

Code

This time you specify the target in the attribute like below

2014-07-17_21-35-39

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

image

You will see

image

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.

2014-07-17_21-43-33

How is the TDL Dataflow visualizer done?

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

2014-07-17_21-47-11

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.