Software Development

All things programming.

Phishing Hook

Today I, along with a number of my friends got duped into clicking on a phishing attack posing as Google Docs link. The offending email essentially states that a document has been shared with you and gives a legitimate looking button enticing the unsuspecting target to click it. Since the email I received appeared to be from someone I’ve routinely share documents with via Google Docs I wasn’t as diligent as I normally would be and followed the link thus opening my Google account to the attack.

This particular attack resulted in many of my contacts being sent the same link. Although this attack compromised my Google account I don’t actively use it for anything beyond logging in to various Google services. That said, I do still have some contacts on there from when I did use it for much more so while quite a few of the emails bounced due to invalid addresses, other legitimate contacts have been emailed, tricked, and therefore affected.

Google has reportedly deactivated the offending app and is investigating the incident but since this paves the way for copycats I thought I’d share the steps for revoking permissions from apps that have been previously been allowed to access your Google accounts. It’s always a good idea to periodically review what you’ve granted access to anyway so without further ado…

1.) Navigate to the Google account permissions page.

2.) Locate the app you want to remove and click it. For example, I want to revoke permission for a Wheel of Fortune game I no longer play so I’ll click anywhere in the row pointed to in the image below. (The app responsible for today’s attack would be listed as Google Docs. I revoked the permissions once I realized what was happening – even before Google shut it down.)


3.) Once the row is expanded, simply kick the “Remove” button.


4.) You’ll then be prompted to confirm removing the app’s permissions. Click the “OK” button to remove the app’s access to your account.


5.) Upon clicking “OK” the app will be removed from the list.


Indy.Code() Coming Soon!

Over the past few years life has taken me on an interesting journey. What started off as blogging led to writing a book, authoring some Pluralsight courses, receiving a few Microsoft MVP awards, and speaking at user groups and conferences around the world. Through all these activities I’ve connected with amazing people doing incredible things and have formed lasting friendships with people I’d likely have had little chance of meeting under other circumstances.

Whether it’s speaking at a conference or leading a class at Eleven Fifty Academy, being engaged in the global software development community, sharing knowledge, and fostering professional growth has become a major part of my lifestyle. Despite how proud I am of the work I’ve done one thing I’ve come to regret over time is how little of my efforts have been focused on my local community. Sure, I’ve spoken at user groups around the Indiana but most of my efforts have been focused in far away places.

Indianapolis, and Indiana for that matter, is primed to be a major player in the technology scene but too often we stay within our silos and fragmented communities. What Indiana has lacked for a number of years is an event to bring the entire community together. Together we’re stronger and that’s why I’ve partnered with my good friends Adam Barney and Ken Versaw of Amegala to bring Indy.Code() to Indianapolis!

Indy.Code() is a three-day conference covering all aspects of software development. It’s being held March 29-31 at the Indiana Convention Center in downtown Indianapolis. We’ve lined up more than 100 hands-on workshops and breakout sessions presented by some of the nation’s best technical speakers including several based right here in Indiana. We’ve also worked hard to ensure that there’s something for everyone involved in software development so whether you’re developing a brand new Angular 2 or .NET Core app, maintaining legacy systems, designing a user experience, or managing a project, Indy.Code() has something for you. Indy.Code() even has dedicated tracks for functional programming, mobile development, and project management! And finally, don’t forget about all the opportunities to connect with your peers. Perhaps you’ll meet someone who inspired your career or someone else who just solved that problem that’s been nagging you for a week.


So what are you waiting for? Don’t miss your opportunity to participate in this one-of-a-kind Indiana development event. Register for Indy.Code() today!

See you there!

C# 6 Verbatim Interpolated String Literals

It’s no secret that string interpolation is one of my favorite C# 6 language features because of how well it cleans up that messy composite formatting syntax. A few days ago I was working on some code that contained a verbatim string that included a few of the classic tokens and I wondered if string interpolation would work with verbatim strings as well.

After a quick glance over the MSDN documentation for string interpolation revealed nothing I just decided to give it a shot by adding a dollar sign ($) ahead of the existing at (@) sign and filled the holes with the appropriate expressions. Much to my delight this worked beautifully as shown in the snippet below!

var name = "Dave";
var age = 36;

var sentence = $@"Hello!
My name is {name}.
I'm {age} years old.";


I later discovered that even though this feature doesn’t seem to be listed in the MSDN documentation (at least anywhere I could find it) that it is explicitly called out in the C# 6 draft specification so hopefully it’ll find its way to the rest of the documentation at some point.

Functional C#: Debugging Method Chains

One of the most common questions I get in regard to the Map and Tee extension methods I presented in my recent Pluralsight course is “That’s great…but how do I debug these chains?” I get it – debugging a lengthy method chain can seem like a monumental task upon first glance but I assure you, it really isn’t all that difficult or even much different from what you’re accustomed to with more traditional, imperative C# code.

I’ve found that when debugging method chains I typically already have a good idea where the problem is. Spoiler: It’s in the code I wrote. That means that I can almost always automatically rule out any chained in framework or other third-party library methods as the source of the problem. It also means that setting a breakpoint within a chained lambda expression or method is often an adequate first step in isolating the problem. This is especially useful when working with pure, deterministic methods because you can then write a test case around the method in question and already have the breakpoint right where you need it.

In some situations though, you want to follow computation through the chain but constantly stepping through the extension methods can be both tedious and distracting, especially when the chained method is outside of your control and won’t be stepped into anyway. Fortunately this is easily resolved with a single attribute.

The System.Diagnostics.DebuggerNonUserCodeAttribute class is intended specifically for this purpose. As MSDN states, this attribute instructs the debugger to step through rather than into the decorated type or member. You can either apply this attribute to individual methods or to the extension class to prevent the methods from disrupting your debugging experience. For my projects I opted to simply suppress all of the extension methods by decorating the class like this:

public static class FunctionalExtensions
    public static TResult Map<TSource, TResult>(
        this TSource @this,
        Func<TSource, TResult> map) => map(@this);

    // -- Snipped --

With the attribute applied, you can simply set a breakpoint on the chain and step into it as you normally would. Then, instead of having to walk through each of the extension methods you’ll simply be taken right into the chained methods or lambda expressions.


Functional C#: Chaining Async Methods

The response to my new Functional Programming with C# course on Pluralsight has been far better than I ever imagined it would be while I was writing it. Thanks, everyone for your support!

One viewer, John Hoerr, asked an interesting question about how to include async methods within a chain. I have to be honest that I never really thought about it but I can definitely see how it would be useful.

In his hypothetical example John provided the following three async methods:

public async Task<int> F(int x) => await Task.FromResult(x + 1);
public async Task<int> G(int x) => await Task.FromResult(x * 2);
public async Task<int> H(int x) => await Task.FromResult(x + 3);

He wanted to chain these three methods together such that the asynchronous result from one task would be passed as input to the next method. Essentially he wanted the asynchronous version of this:


These methods can’t be chained together using the Map method I defined in the course because each of them want an int value rather than Task<int>. One thing John considered was using the ContinueWith method.

    .ContinueWith(t => G(t.Result))
    .ContinueWith(t => F(t.Result.Result));

This approach does play well with method chaining because each method returns a task that exposes the ContinueWith method but it requires working with the tasks directly to get the result and hand it off to the next method. Also, as we chain more tasks together we have to drill through the results to get to the value we really care about. Instead what we’re looking for is a more generalized approach that can be used across methods and at an arbitrary level within the chain.

After some more discussion we arrived at the following solution:

public static async Task<TResult> MapAsync<TSource, TResult>(
    this Task<TSource> @this,
    Func<TSource, Task<TResult>> fn) => await fn(await @this);

Rather than working with TSource and TResult directly like the Map method does, MapAsync operates against Task<TResult>. This approach allows us to define the method as async, accept the task returned from one async method, and await the call to the delegate. The method name also gives anyone reading the code a good visual indication that it is intended to be used with asynchronous methods.

With MapAsync now defined we can easily include async methods in a chain like this:

await 1

Here we begin with the synchronous Map call because at this point we have an integer rather than a task. The call to H returns a Task so from there we chain in G and F respectively using the new MapAsync method. Because we’re awaiting the whole chain, it’s all wrapped up in a nice continuation automatically for us.

This version of the MapAsync method definitely covers the original question but there are two other permutations that could also be useful.

public static async Task<TResult> MapAsync<TSource, TResult>(
    this TSource @this,
    Func<TSource, Task<TResult>> fn) => await fn(@this);

public static async Task<TResult> MapAsync<TSource, TResult>(
    this Task<TSource> @this,
    Func<TSource, TResult> fn) => fn(await @this);

Both of these overloads awaits results at different points depending on the input or output but they each operate against a Task at some point.

So there you have it, a relatively painless way to include arbitrary async methods within a method chain.

Thanks, John, for your question and your contributions to this post!

Have fun!

Functional Programming with C# is Live!

After a few months in the works I’m excited to announce that my second Pluralsight course, Functional Programming with C#, is now live! In this course you can learn how to take advantage of several functional programming techniques including immutability, higher-order functions, and functional pipelining within your existing C# projects.

If you’re a .NET developer interested in functional programming but not yet ready to jump to F# or just want to leverage functional techniques in your existing projects please check it out!

Crashing Visual Studio 2015 with Explicit Interface Implementations

In F#, all interface implementations are always explicit meaning that the interface methods will only be accessible when treating the implementing type as that interface. This makes sense in F# because it removes all ambiguity around what the method applies to. Explicit implementations also force us into coding to the interface because other miscellaneous members of the implementing type aren’t exposed through the interface definition. For these reasons I’ve been hooked on explicit interface implementation and even use it almost exclusively with great success in my C# applications.

Imagine my surprise then when Visual Studio 2015 crashed when I tried to rename an explicitly implemented interface method! The first time it happened I figured it was probably just Visual Studio misbehaving but when I reopened the solution and tried again the same thing happened! Clearly there was something more to this.


Renaming an explicitly implemented interface method causes Visual Studio 2015 to crash.

Hoping that I’d perhaps stumbled upon something that was fixed and included in Update 1, I upgraded Visual Studio and tried again. The crash still occurred.

To narrow down the issue I created a brand new solution with a console application. Within the new project I defined a simple interface with a single method and explicitly implemented it in a class. At this point I attempted to rename the method and it worked as expected. I then tried renaming the interface method directly on the interface and that also worked as expected. Then I figured that it must have something to do with how the interface was being used so I created an instance of the class, converted it to the interface, and tried the rename again and it was successful. Finally, I added a line to invoke the interface method and tried the rename one more time. Oddly, it again worked as expected.

On a whim I decided to move the interface and implementation into a separate project. After adding the project reference and doing a test build I again tried to rename the method and sure enough, Visual Studio crashed. I’ve since played with a few different combinations and have been able to successfully recreate the crash as long as the interface is defined in a separate assembly and I tried renaming the method via the explicit implementation.

In summary, it appears that in order to recreate this crash the following conditions must be met:

  • Interface must be explicitly implemented
  • Interface must be defined in a separate assembly than where it’s used
  • Rename must be attempted against the explicit implementation
  • Interface method must be invoked – simply creating an instance won’t cause the crash.

I’ve submitted the issue to Microsoft on Connect but this seems like such an edge case I’d be surprised to see a fix anytime soon. In the mean time, if this is something you encounter you can safely rename the method on the interface itself or at the call site; neither of those seemed to be an issue.

If you’d like to mess around with this issue on your own, I’ve shared my sample project on GitHub.