Creating a VS Extension

 I'm a moderate user of extensions. As in, I have some favorites, but I'm not trolling the gallery everyday.

I've never made one before. No idea has either been both big enough and small enough to warrant me building an extension.

In April 2016, at Build, I saw Mads Kristensen create & publish (with integrated CI, and pretty images) a brand new extension during a 1 hour session. It was a great talk, and I had promised myself that I would watch it again on Channel9. I also signed up to be a VS Partner while at build.

I received an email about a week ago saying my VS Partner status would be canceled, unless I published a product in the next week.

Two days later, I came across a fitting challenge for an extension. So I set out to build it.

I followed Mads' video, and it was surprisingly easy. The docs are still very confusing for the VS interfaces, but it was still doable.In the end, what took Mads less than an hour on stage, took me about 5 hours of total work at my desk.

All in all, it was still surprisingly easy, and I regret not doing it sooner.

How yield Works

This code should work:

IEnumerable<T> ShouldWork<T>(T  obj)
{    
    if (!obj is IEnumerable<T>)
    {
        yield return obj;
    }
    return (IEnumerable<T>) obj; 
}

But it doesn't.

I thought it would work. I like using yield to take full advantage of delayed enumeration, rather than creating new lists or arrays all the time.

Everything looks right; the return types are good. Except it won't compile. You get a nice message about having to use yield inside an iterator when trying to return (IEnumerabl<T>)obj directly.

Don't try yield return (IEnumerable<T>)obj. That will do exactly what you'd think. It won't compile either, because now the return types don't match, because yield return (IENumerable<T>)obj needs a method return type of IEnumerable<IEnumerable<T>>.

So what to do?

Obviously, try yield break. Because nothing else is making sense at this point. But of course, that's not what yield break is for in the least, so it doesn't work. Yay, not completely crazy.

This issue didn't come up for me until I was trying to combine recursion & LINQ-expressions. And was stumped. Googling the motivator (LINQ and recursion) yielded (pun intended) no valuable results.

I grabbed the nearest .NET nerd of my colleagues, and went straight to the whiteboard. In doing so, I realized that recursion has nothing to do with this not compiling (still not crazy!). On the other hand I still had to convince my colleague that the code wouldn't compile. (He went thru literally the same steps I did. Again, not crazy).

So we seem to have found a cool nugget in the compiler, that seems to say, "if you want to yield return once in a method, you must yield all other returns in that method." OK. That actually kind of makes sense. Delayed enumeration would mean that the compiler is wanting to deal w/ things granularly.

My (sad hack of a) solution: Fake the yield.

IEnumerable<T> DoesActuallyWork<T>(T  obj)
{ 
    if (!obj is IEnumerable<T>)
    {
        return FakeYield(obj);
    }
    return (IEnumerable<T>) obj; 
}

IEnumerable<T> FakeYield<T>(T obj)
{
    yield return obj.
}

All that to avoid explicitly instantiating lists.