If you’re working on a MEF (Managed Extensibility Framework) application, you’re probably familiar with its ups and down. On the one hand, MEF is a powerful plugin system, that’s a pleasure to work with once you know it well. On the other hand, we all encountered strange failures that originated with MEF. Such failures are a nightmare to debug and identify. There are several reasons why a MEF failure might happen.
I recently had to create a Roslyn Analyzer that envelopes code in a try/catch statement. This reasoning was to prevent loading errors in any exported MEF component . Here’s the analyzer in action: The analyzer does the following: Adds a Diagnostic that finds a MEF ImportingConstructor with content that’s not entirely wrapped in a try/catch statement. Provides a Code Fix to handle the problem. The Code Fix will: Add a try/catch statement around the entire content Add ErrorNotificationLogger.
In part 1 , we saw how C# has evolved from its inception in 2000 to the C# 3.0 release in 2008. C# did not introduce a revolutionary syntax or even revolutionary features. Instead, C# imitated most of its features from C++, Java, Scala, and several other languages. As is the Microsoft way, C# imitated many things but did it better than original. The most outstanding example of that is Generics.
Around the year 2000, Microsoft developed the C# language (led by Anders Hejlsberg ). This language, along with the .NET framework had a significant strategic purpose. Microsoft would create a better language tied to Windows, driving customers to the Windows ecosystem and Microsoft products. Perhaps this was part of the notorious Embrace, extend, and extinguish Microsoft strategy (now in the past). This development came in response to Java, which has gained enormous popularity by then.
Did you hear about stackshare ? It’s a pretty neat website that I recently discovered. The idea is that you can search for any tech company, and see their technology stack. For example, here is Airbnb’s: So the first interesting thing that came to mind was checking out what the most successful startups are using. I used this list of “successful startups”, in addition to angel.co startup database. After looking at about 100 startups, I ended up with data from 23.
I recently encountered an interesting challenge: How to display a .NET object’s properties in an expandable tree view? This is something we constantly use inside the Visual Studio debugger: The debugger’s data tip control is exactly what I needed. An input would be any .NET object, and the result should be a tree view displaying the object’s properties and fields. I figured there would be an easy solution I can google and copy-paste, spending no more than 10 minutes on the whole thing.
Tutorial Table of Contents: Part 1: Introduction to VS extensibility Part 2: Add Menu Item Part 3: Add command to context menu and get selected code Part 4: Show a popup Window Part 5: Highlight code in Editor Part 6: Follow a span of code with TrackingSpan Part 7: Insert buttons between text characters with Adornments During the tutorial we are going to build a VS extensions called CodyDocs and place it on GitHub .
In the modern world, we are dependent on dozens of libraries. These in turn, depend on dozens more and we end up with hundreds or thousands of dependencies. So now the problem arises for a single application. What to do when several of its projects depend on different version of the same assembly?
Fixing bugs is a huge part of a developer’s job, but not many think or read about the actual process of solving a bug. We sort of go at it intuitively, trusting our own self-developed process. Some of us tend to think of bug solving as the 2nd class citizen in programming. Not our real job, which is writing code, crafting new features and discovering new technologies. It’s just something we do in between real programming, right?