Welcome C# Interactive Window (or: Visual Studio Debugging Tips – #4)

TL;DR – Once you try the C# Interactive Window, you will never run another Console App just to try out an API.


interactive-window-pic


You know how they say that if the only tool you have is a hammer, then everything looks like a nail? Well, this is especially true in the software industry. I once witnessed a guy debugging a .NET application with WinDbg  just because he is a guru of that tool. At that moment I thought to myself how happy he would be if he only knew the tools available to him with Visual Studio.

Anyway, enough with the jabber, I am here to make you fall in love with the C# interactive window that is available with Visual Studio 2015 update-1.

After finishing the update of you VS, navigate to:

View > Other Windows > C# Interactive

What you should see is a new window that looks like this:

interactive-wnd



Features, features and features…

Alright, after getting all the boring stuff out of the way, I want to show you what you can do with this. The whole set of features is explained on the official Microsoft GitHub account, so I wont cover everything but give you a taste of the most interesting ways you can use it in your day-to-day development.

    1. Multi-line support – you can write fully executable script by pressing ‘Shift+Enter’ for a new line, and for actual execution use ‘Ctrl+Enter’ when your script is ready. Consider this snippet:
      interactive-wnd-loop

 

    1. Reference external dlls – you can actually load an external dll to play with it’s APIs by using the #r command like this:
      interactive-wnd-loadlibrary
      This is seriously a powerful tool!

 

    1. Use interactive outside VS – you can run this environment even outside Visual Studio by simply executing  ‘csi’ in you Developer Command Prompt from VS 2015:interactive-csi

 

    1. Loading saved scripts – you can write a common script and load it in to the execution context by using the #load command. This is super cool when you have a script that is loading an entire environment for you that you can work with with specific APIs.

 

    1. Execution context – when the window initializes, you can create variables that will live until you type the  #reset command. For example try executing the following command, and use the myFile variable in your next commands:var myFile = new FileInfo(@"c:\users\shonn\desktop\myResume.txt");

 

    1. Navigation – You can navigate executed statements history by using ‘Alt+UpArrow’.

 

Go ahead and explore more features (believe me there are tons!), it is really awesome!

Feel free to leave a comment if this was helpful 🙂
Shonn Lyga.


 

Posted in .NET, Debugging | Tagged , , , | Leave a comment

Source Server with Git Repository

Update [29.9.2016] – Due to numerous emails, I wanted to post the exact command I used in my Continuous Integration builds:

 

TL;DR – How I enabled “Source Server” support for an internal Git repository for any Git provider even when authentication to the server is required. I ended up setting up a tiny Web Api service that queries a local clone of a repository on the server and returns a raw file content from a specific revision.

KeepCalmStudio.com-[Crown]-Keep-Calm-And-Use-Source-Server.png

 

Lets review the big picture and explain the motivation for what I tried to achieve here. If you know what ‘source server’ in Visual Studio is – feel free to skip to ‘The solution‘ section below.

Source Server

How many times you wished you could step into source of some referenced assembly in you project that you don’t own the actual sources for? Well, when you enable the Source Server option in Visual Studio, you basically tell the Debugger to check the .pdb file to try and bring the sources from the location encoded in the .pdb file. Even after using this feature at least a 100 times, it still feels like magic to me when the actual source file suddenly appears in my debugger.

 

.pdb who?

So now we know that the debugger can fetch the relevant sources for you as long as you have the .pdb file that the debugger can look into to find the location of the sources on the internet. But what are those .pdb files and how can you get them?

Lets say you have a C# library project loaded in visual studio. When you compile the source code with ‘Debug’ configuration, your output would contain your .dll file with the compiled code, and a .pdb file that will contain information for debugging your library. (more on .pdb files HERE)

If you try opening the .pdb file, you will see lots and lots of binary gibberish, but if you scroll to the end of the file, you will see textual content that looks something like this (taken from xunit.assert.pdb):

pdb text.PNG

 

What you see here, is the info that tells Visual Studio where to get the actual sources for this specific revision in case you want to debug the library and step into their source. Of course you can’t access ‘C:\TeamCity\buildAgent’ on the actual machine the library was built on, so if you look carefully, there is an ‘*’ that separates variables and adds the relative path variable the debugging tools will use to try and fetch the correct source from a publicly accessible location that is specified in the ‘SRCSRVTRG‘ variable.

Ok, so now we know that basically all we need to do is to instrument our.pdb files upon build with the textual information that will assist the debugger to retrieve the right file from the exact revision. The good news is that Microsoft supports such instrumentation of your .pdb files and even provides you with the right scripts to do so. I have no clue why, but those Micrisoft scripts are written in Perl (oh God, do I hate Perl).

You can get all the relevant scripts when installing the Windows SDK. They should reside in a path that looks something like this:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\srcsrv

 

The problem

What we’ve go so far, hopefully, is the understanding of what are symbols and how we can debug sources that we don’t actually own. The problem is, that Microsoft is only supporting couple of version control systems that the debugger can fetch sources from with the help of a .pdb file. In the company I work for, there is a desire to migrate to a Git source control system – Stash\Bitbucket.

One of the reasons we are struggling with the migration is due to lack of support for Source Server over a Git repository. Meaning, if we have a CI system that builds our sources from Stash, the debugger will not be able to fetch the relevant sources shall we want to debug some specific .dll library that we deployed to production.

Even if we find a way to instrument the .pdb file to try and fetch sources from Stash, there are 2 issues that stop our debugging:

  • Our Stash\Bitbucket Git server needs an SSO authentication to access any repository.
  • To query the Stash\Bitbucket Git server we need to build a URL with query parameters while the debugger will not fetch anything that contains “?” symbol in the URL (seems like a known issue in the srcsrv.dll).

The solution

I’ll get right to the point – I decided to write an ASP Web Api service that will accept a true REST call (without any query parameters) and will use a server-side clone of the relevant Git repository to fetch the exact revision of a file. By doing so, we solve both problems:

  • We don’t need any SSO authentication because we are using a local clone of the repository over at the Web Service (which actually makes the solution agnostic as for the Git source control we are using).
  • We don’t have to create a URL with query parameters anymore, because the Web Api service will accept a clean RESTfull request.

Ok, right about now you should be asking “hey, but how is your service querying the local Git clone on the server? Did you write your own library?”.  Of course not, I used a library called libgit2Sharp that helped me query my sources simply like this:

getfileatrevision

So right now, with some out-of-the-box thinking, we solved the problems we had with getting the relevant revision of a specific file that is stored in a Git repository. While this is solved, we have another problem, how the hell are we going to instrument our .pdb files upon build to make the debugger talk to our Web Api service and load the correct sources in Visual Studio?

Enter GitLink! No more cryptic Perl scripts, just plain ol’ C# that will instrument all your .pdb files that are created when building your projects. I wont get into the nuts-and-bolts on how to use this tool, it is pretty straightforward with good documentation on GitHub, but I will mention couple of things I had to solve myself and recompile the latest GitLink sources with my own changes.

(You can see all my changes in this revision HERE)

Change #1: The GitLink command line is expecting my service to talk via https, so I removed the need for https since my service is running via http.

Change #2: This is an important one, when instrumenting my .pdb files with GitLink, I opted in using powershell for fetching the files from my Web Service. But the original code did not work no matter how hard I tried, the Visual Studio debugger did not want to go and fetch my files. So i fixed the command in GitLink to use this line (you can find it find in source):

“SRCSRVCMD=powershell invoke-command -scriptblock {param($url=’%RAWURL%’, $output=’%TRGFILE%’); (New-Object System.Net.WebClient).DownloadFile($url, $output)}”

Change #3: When instrumenting .pdb files, you can’t use relative file locations in your REST call because of the ‘/’ character. I changed the code to replace each slash with a placeholder like this: {__slash__} so when my Web Service gets a request, it first replaces the placeholders with actual slashes before querying the local Git clone of my repository.

 

Conclusion

Let me go back to 50k foot view, and draw the full picture here.
When you build your project in Visual Studio in Debug mode, your output will contain your .dll library file and a .pdb file.

After you have your build artifacts, you will use GitLink to instrument your .pdb files so they know how to fetch the relevant sources when you want to debug the code.

After instrumenting you .pdb files, you will deploy them to your Symbol Server and point your Visual Studio configuration to use that Symbol Server.

Next, when you wish to debug the exact same version of your .dll, you will try stepping in to any method in that library while debugging, then the Debugger will go get the relevant .pdb file from your Symbol Server and use it to find info you put in the .pdb that lets the Debugger get your sources.

The debugger will use that information to call your Web Service and fetch the exact revision of your sources files. The debugger will then load that file automatically and you will be able to debug the code.

 

Last thoughts

 

Only when writing your own blog posts, you understand how hard it is to explain something like this in a written document. I tried to do my best, but if you still have any questions, don’t hesitate to contact me and I will do my best to help out with the implementation.

 

Shonn Lyga.

 

 

 

Posted in .NET, Debugging | Tagged , , , , , | 6 Comments

Visual Studio Debugging Tips – #3

TL;DR – Use the ‘Modules’ window do view the assemblies loaded at every point of the application’s lifecycle.

making_modules

 

Initially i did not plan to write about this, but after observing a team trying to figure out what assemblies are being loaded in to their app’s process, i thought to share this small tip.

So what do you do when you hit a breakpoint in Visual Studio, and all you want is to check what assemblies are loaded, their version, their physical path etc…?

Visual Studio supports this little feature called “Modules” window that can be viewed only when you are in debug mode. To inspect this window, go to

Debug => Windows => Modules  (or press Ctrl+D, M)

menu.png

 

What you should see is a ‘Modules’ window that pops out

modules

 

If this is the first time you see this window, you will not believe that you’ve been living without it until now. No more wondering when, what and what version is being loaded, just step through your code and see the Modules list updated with the relevant information.

 

Happy debugging!
Shonn Lyga.

 

Visual Studio Debugging Tips – #1
Visual Studio Debugging Tips – #2

 

Posted in .NET, Debugging | Tagged , , | 2 Comments

Visual Studio Debugging Tips – #2

TL;DR – Find out how your application is locating, resolving and loading your dependencies using FusionLogs and fuslogvw.exe

assembly-point

 

Motivation:

We love black boxes. I don’t mean actual black boxes, but rather software components that provide us with some sort of a service (or output) given a certain input. We usually don’t care how the box does it’s magic, all we care about is that it works. This enables us to write software faster and be much more productive by using existing boxes that were created and tested for us. As we all know, in software we are “Standing on the shoulders of giants”.

Sooner or later there comes a time when one of those boxes does’t work as expected, and that is where lots of developers ‘waste’ precious time on debugging and figuring things out. Understanding the basics and the tooling available for the tools or frameworks that we use allows us to overcome black-box issues fast and become a lot more productive.

Recently i noticed that some developers are sometimes jumping through hoops to find why their program fails when the misbehavior is in some black-boxed component they use in their application. Most of the time it is due lack of knowledge on the basic tooling available for them to debug and resolve issues in those black-boxes.

This post will talk about one black box called ‘Fusion‘ and a pretty neat way of debugging it’s behavior.

 

What is Fusion:

Fusion is a subsystem in .NET that is responsible for locating and loading the Assemblies that your application uses at runtime. After locating the required dependency, Fusion will load that Assembly in to the correct AppDomain to be used by your program.

 

Nuts and Bolts:

When you install Visual Studio, you get a great tool called fuslogvw.exe that allows you to easily trace every issue you have with assembly bindings in your application. You can trace exactly where and how ‘Fusion‘ is looking for and loading your dependencies.

Fusion can log it’s full process of resolving dependencies of your application, versioning issues, probing locations etc… While you can edit a registry key to enable this feature, it is nicer to use fuslogvw.exe.

Just run your Developer Command Prompt that you have on your machine, run the command prompt ‘As Administrator’, and type fuslogvw and press Enter.
devCmd

At this point you should see this simple form on the screen:

fusionform

If you ran the tool as Administrator, you should be able to change the settings of this application. Press ‘Settings’ and a dialog should pop-up.

settings

In order to get a taste of the tool and it’s usage, set your settings as shown in the picture above.
This should start logging all Fusion activities on your disk in the specified location. After running one of your applications, press ‘Refresh’ and you should see new entries in the main window of fuslogvw.

Double-click on any of the entries and check out the logs. The information there is pretty amazing. After browsing through the logs, just think of the next time you get a TypeLoader or Assembly binding issue and you will have to inspect the exact dependency loading process or versioning. This will save you some precious time!

 

Remember:

After using the tool, don’t forget to turn off fusion logging at some point or clear the logs directory once in a while because pretty quickly this directory may grow to a huge size on your disk.

 

Happy debugging,
Shonn Lyga.

 

Visual Studio Debugging Tips – #1
Visual Studio Debugging Tips – #3

Posted in .NET, Debugging | Tagged , , , , | 1 Comment

Visual Studio Debugging Tips – #1

TL;DR – In Visual Studio, you can ‘pin’ an object instance and inspect its state at any point during the lifetime of your application and even using the pinned object as a breakpoint condition.

 

It has been a long time now that i really wanted to make a series on the Visual Studio advanced debugging tips and tricks. In this series i won’t cover anything that seems trivial for my taste, rather i will talk about some of the less ‘popular’ features of the Visual Studio debugger.

Pinning

As it turns out, a lot of developers out there are not aware of the many amazing features Visual Studio brings into their professional toolboxes. One of them is ‘Object Pinning’.

 

Lets start with some use cases and common solutions.

  1. When you hit a breakpoint in a function and you want to inspect this function’s variables, you can look at the ‘locals’ window in VS.
  2. When you hit a breakpoint in a function that is X stack frames deep, and you want to inspect one of the calling function’s variables, you will use the call stack window.
  3. So far the problems and their solutions have been trivial. How about inspecting an object instance that is not in your function’s scope, and not in you call stack scope either?

 

Well, there is a pretty simple solution, and its called ‘Object Pinning’. When you hit a breakpoint, you can add an object to a ‘watch’ window by right clicking the variable and choose ‘Add Watch‘ from the context menu.

watch

 

Once the variable is in the ‘Watch’ window, you can right click it and choose ‘Make Object Id‘ from the context menu.

id

 

At this point VisualStudio will assign a number to this instance, and you will be able to inspect the object at any point in your application by typing the dollar sign ($) and the number of the instance next to it (if this is the first time during the lifetime of your application that you are pinning an object, then your object should get an id of $1).

 

Here is the interesting part, you can actually use this pinned object as a condition for a breakpoint! This is amazing really, i encourage you to try this out on your own.

Have fun coding,
Shonn Lyga.

 

Visual Studio Debugging Tips – #2
Visual Studio Debugging Tips – #3

Posted in .NET, Debugging | Tagged , , | 2 Comments

Dangers of the ‘nameof’ Operator (c#)

TL;DR – The are hidden dangers in the ‘nameof’ operator in c# 6.

shotinfoot

 

Lately I have witnessed developers use new features that were presented in c# 6. My problem is not with using the new features, but with developers blindly refactoring their code just so that their code is “cutting edge” using and abusing the new language features without giving it much thought, as if their change is purely syntactic and does not change anything in the semantics of their program.

 

The are some very interesting and useful new features in c# 6, like string interpolation or the property auto initializers. But in this article I want to talk about the ‘nameof’ operator.

 

In short, the ‘nameof’ operator lets the developers be less dependent of pure string values. Here is a usefull example:

public string Name
 {
     set
     {
         // some setter code
         NotifyPropertyChanged("Name");
     }
 }

 

Imagine that now you want to refactor the property ‘Name’ to ‘FirstName’ because of some new requirements. You would need to always remember to change the string “Name” anywhere it was used, just like in the above example.
The new ‘nameof” feature allows you to write code as follows:

public string Name{
   set{
        NotifyPropertyChanged(nameof(Name));
    }
}

 

In this case when refactoring the ‘Name’ property, all uses in the ‘nameof’ operator will be refactored automatically with the help of your IDE.

 

So how can you shoot yourself in the foot with this operator, you ask? Pretty easily. And when you do – its pretty ugly, Lets see an example.
Consider the following code that extracts a value from configuration by providing a key:

Name = ConfigurationManager.AppSettings[nameof(Name)];

 

What would happen to this statement after the above mentioned refactoring? The result would be unpredictable. You might get an empty value, or maybe worse – you might get a value of some other key in the configuration file. This is pretty bad, I hope you see why.

 

This example is a simple one, but when you have a team working on the same code-base and some of the developers abuse the ‘nameof’ feature, you start dreading refactoring since you have no idea what you might end up braking.

 

To conclude, don’t blindly apply the shiny new features of your language just because they exist, use it when it’s appropriate. As a rule of thumb, I would suggest avoiding using the ‘nameof’ operator when used as a key in a key/value pair.

 

Enjoy coding,
Shonn Lyga.

Posted in .NET, General Software, Software Design | Tagged , , | Leave a comment

NuGet restore failed – Asp.Net Core

After battling with this for an hour, i though this might help anyone with the same problem. I am not entirely sure how this fixed the problem, but it did.

 

After updating the NuGet package manager, i created a simple Asp.NET Core 1.0 project and tried to compile it. This resulted in multiple errors that looked like this:

 

“NuGet restore failed. Response status code does not indicate success: 404… “

 

I added another API endpoint for NuGet to search for packages, and it did the trick.
The URL is: https://api.nuget.org/v3/index.json

 

NOTE: If you are using any private repositories that are currently unavailable within your network, then you might need to disable them in Visual Studio NuGet feeds settings.

 

As i understand, this is the URL you should use for NuGet v3 and Visual Studio 2015.

I updated to NuGet v3 but did not add the additional repository URL.

 

 

Posted in .NET Core | Tagged , , , , | Leave a comment