Leaning Into Windows

EventSource: A New Way to Trace

2013-05-03T22:21:00Z

Module 3 Highlights

This is the next installment in my series of high points in .NET 4.5, which parallels my Pluralsight course “What’s New in .NET 4.5”. I think the course offers important insight and details into the release, and if you’ve already watched it, this will give a second explanation of the most important features. If you don’t watch it, you can follow along with the most important features I cover.

First two installments of the course highlights are here and here.

What’s New?

Tracing becomes more and more critical as our applications move onto remote servers and into the cloud. Even with other tools available, desktop applications still need tracing to determine what the user was doing when a problem appears. Debug mode is rarely an option in production.

Microsoft’s answer is high speed unified tracing within the operating system: Event Tracing for Windows. ETW has been around since Vista, so it’s hardly a news flash. What’s new in .NET 4.5 is that ETW goes from being a royal pain to use to being one of the most simple and elegant features of .NET. This change makes ETW support and the new EventSource class is the sleeper feature of .NET 4.5 – the most important feature you never heard of.

So, let me explain, and hopefully inspire you to completely rethink your tracing strategy. Warning, if you’re fantasies get too carried away, I’ll knock a few over when I cover shortcomings near the end of the post.

While I won’t cover it hear, the Semantic Logging Block Patterns and Practices is using unifies ETW with traditional trace output locations and plus a couple of holes. So, if I get your attention, you may also want to explore what they’ve done – same underlying tools and syntax, with some important additions.

ETW

ETW is a high performance tracing system built into the operating system. It’s a fully composite system with some extreme extensibility options. There are four moving parts – ETW itself, providers, controllers and consumers. Because it’s a completely interchangeable system, not only can you come up with your own providers, controller and consumers to support ETW, you can replace ETW with something else filling it’s role – allowing alternate tracing options such as Silverlight support. That’s amazing, but the important parts to .NET 4.5 are providers, consumers, and controllers.

Consumers are important because the OS creates the smallest possible binary output to meet its goal of not hurting performance with tracing. There are a number of task specific consumers, including Visual Studio tooling, such as WCF tools and the Concurrency Visualizer. A good general purpose tool to consider is PerfView. And if you want, or need, to write your own tooling, you can use PerfView’s underlying libraries to access the binary stream. Or, if you need to party on raw trace events, you can get the binary stream transformed into XML output.

Controllers turn ETW on and off. Gone are the days of stopping your server, changing a configuration setting, and restarting the server – only to repeat in order to turn tracing off. Controllers communicate to providers whether they are on or off, and can do this to running applications. Tracing can be turned on before your application starts, as part of startup, or as the application runs. Controllers also communicate filtering information such as severity level to providers.

Providers create trace events. The operating system, .NET and other libraries are already fully on board. Right now you can fire up PerfView and get information on your application, including crashes. The purpose of the new EventSource class is to let you add events to this holistic stream.

Providers create trace events, controllers turn tracing on and off, and consumers do something with the resulting trace. Central to the design is a stream of trace events (actually a few streams, called channels, see more below). It doesn’t matter if the trace event is created by your application, the operating system, the .NET framework, WCF, or anything else.

This creates a fundamentally different approach to tracing because you don’t have much work to do. Almost everything you want to know is already in the trace system.

A New Way of Thinking about Tracing

If you’ve done tracing before, you probably worked to create a reasonably complete picture of what was happening in your application - you took responsibility for providing all of the relevant information. That’s changed. Since other providers are already dumping information into ETW you can think of the trace stream as a river with all of the information you can imagine flowing passed.

Your job is simply to complete the picture. The river has no context without your help. The surface is just a series of waves with no relation to what’s actually happening. Throw in key buoys about what you’re doing, and suddenly the part of the river adjacent to your buoy makes sense.

The markers you throw out can contain information like the current record. But remember the earlier caveat – what you put into the ETW stream with EventSource will be visible to whomever asks for it. You can’t put in sensitive information. Let me say that again – do not put any information into the ETW stream that can’t be seen by people with access to your servers.

Strong Typing and Manifests

One of the important ways ETW differs from some other approaches to tracing is that the information you provide is strongly typed. If you record primary keys and tables, you can find a trace vent with a particular primary key from a particular table. You can then watch that thread or process for information on the process that occurs.

To keep tracing blazingly fast, the operating system creates the trace as a binary stream of goo. Turning goo into strongly typed events requires en event specific definition, which is called a manifest in ETW.

Prior to .NET 4.5 you could create your own manifest or skip the strongly typed benefits of ETW. It’s icky work to create your own manifest and you have to install it on the machine that interprets the trace. This is really problematic if you version your trace event structure (and trust me, you will) because the machine may need to interpret traces from many other machines.

.NET 4.5 and the EventSource class creates the manifest for you and sidesteps manifest issues by using an “in-line manifest.” That’s just another event that contains the manifest. As long as the consumer knows how to grab that special manifest event and use the attached manifest (and PerfView does) all your manifest problems are solved.

EventSource

The ETW goodness in .NET 4.5 is wrapped up in the EventSource class. The second best source of information on ETW (I like my Pluralsight video) is Vance Morrison’s blog posts, such as this.

While Vance’s posts do a great job, and this post is important, this particular post doesn’t mention that you should probably define your event id’s and provider name. Before you add tracing to your own application, be sure to understand those two features.

It’s Not All Joy – Bad Tooling

I said I might knock over your fantasies a bit. The biggest problem with ETW is a lack of good tooling. Please help pressure the Visual Studio team to supply an awesome consumer and at least a decent controller. Interpreting traces is hard and we don’t all need to work out the tricks.

PerfView is the best tool I know of now for the things you’ll need to do. But imagine Microsoft releasing the tool one dev made for their own use and it sort of spiraled into general use by those brainiac softies, and then (thank goodness) they released it to use. You won’t be too far off the mark. But from that you might guess that the important parts are open source, so you can use the underlying library to build your own tool. You’ll find the TraceEvent library on the BCL team’s CodePlex site.

It’s Not Complete – Channels, etc.

The other issue with ETW right now is hard to complain about. Once they got to the edges of what they needed and problems they understood – largely around profiling the .NET framework itself – they slowed down. I don’t think this is laziness, but an honest desire to get it right. I think the most obvious place you’ll see this is the lack of channel support.

ETW supports four channels. While you can define your own, I haven’t yet seen a good use case. The well-known channels are Admin, Operational, Analytic and Debug. EventSource tracing aims at the last – events by devs for devs. Your IT folks (and probably you as well) use the Windows Event Viewer to gauge system healthy. At present, trace events you create with the EventSource class do not show up in Event Viewer because they aren’t admin events.

I was initially appalled by this omission, annoyed that it felt like they ran out of time. But I’ve evolved my thinking. Event Viewer and trace events for the purpose of system health monitoring and warm fuzzies for your IT staff, are inherently different than profiling and debugging information (which overlap). Specifically, you want bells and whistles for filtering and you want to filter extra events at the point of consumption (assuming they aren’t so extreme that they affect performance).

Your IT folks probably don’t see it that way. They probably want your apps to tell them what they need to know when they need to know it. “Just the facts, ma’am.” And maybe strong typing doesn’t matter very much. Let’s start a conversation about the best ways to get information into the admin channel.

Semantic Logging Application Block

I’m just getting into this, but I’m excited about what I’m hearing about the Semantic Logging Application Block (other than its name, and it’s even worse acronym, but I’ll survive). You can get info on the CTP here and here.

I’m really happy that P&P is building on the good work of the BCL team and building on it in ways that make sense to business programmers. What most catches my eye is that you’re EventSource derived classes can be used to write to ETW or more traditional trace listeners. I hope to have time to explore the Semantic Logging Application Block in the coming weeks and post a more thorough discussion.

Why a Women In Technology Luncheon

2013-05-02T18:05:00Z

I just read this post by Samantha Houtsand and it annoyed me. No, it pissed me off. She hasn’t been to a “Women in Technology” event since a bad one in high school and explained to the world what WIT events are. She entirely mischaracterized a specific event that she did not attend.

“My initial hesitation about going to the luncheon had gradually grown into a vehement denial that the luncheon should exist in the first place. What was the point of it? Was it a support group? A private club with a "no boys allowed" sign stuck on the table? “

Depending on whether I had a talk following the luncheon at that specific DevConnections she attended, I was there, and possibly on a panel. Had she gone…

She probably would have seen Michelle and Julie and a lot of other awesome women – speakers and attendees.

Folks would have asked questions like “I’m a bit intimidated about letting my team know I’m pregnant” (Samantha brought this up) and gotten an answer like “it’s probably not going to be a problem, follow a gut and know who your friends are.”

She might have heard from someone that had a bad work situation, with advice something like “create the scenario where you can move on and find a better fit,” probably with a gentle tough love comment about what the person was doing to prepare for those new internal jobs as well.

She probably would have heard from someone asking about work/life balance. She would have realized that no one, famous or not, thinks they do it very well.

There’s a good chance she would have heard a question about increasing visibility or technical skill set. The answer would have been “hard work,” along with some roadmap signposts specific to their goals.

Someone would probably have asked about how we get more young women into technology. That’s not just an IT question – we’re doing badly in all technical fields except medicine. A lot of stupid things would have probably been said, there’s no good answer.

She might have heard someone ask about encouraging a young person to consider this industry. Someone might have mentioned professional Barbies and hopefully someone would point out the importance of gender neutral gifts (LEGOs are gender neutral !!!!) for nieces, nephews, etc.

There would have been a couple of specific technical or entrepreneurship questions that were answered or taken off line.

“Oh, crap, we’re out of time”

None of this is whining. It’s a conversation about issues – in a mostly female environment (men often come, and I would never support excluding them).

If she had attended the luncheon, she would have made a few contacts of technical or business interest. If she was attending the conference alone, she would have had more friendly faces. And if she wasn’t shy, she could have done the same things in the main lunch area.

“What bothers me about "women in technology" is the apparent need to beat their bosoms and proclaim that the industry must change to accommodate them, must recognize that they exist, must treat them equally!! -- but differently.”

I have never met the women that she describes here. Never. Anywhere. Nada. I’ve met tens of thousands of developers, and a number of IT pros, and I’ve never met women that wanted the industry to offer more than common decency and fairness. Send me the links where women are asking the industry to accommodate them or think they need or should have “special treatment” (from a comment on Samantha’s blog). I’ve heard people make this claim, but show me the evidence - when and where!

Having lunch together does not equate to bosom beating. Being inspired by amazing women like Cathy Sullivan or Rhonda Layfield (both have been on past panels) is not bosom beating. Asking questions across the table or of the panel is not bosom beating.

Why did I write this? I’m tired of seeing mischaracterization of women in this industry. We aren’t a bunch of whining angry bosom beaters, any more than the jobs we fill are “men’s jobs.” Samantha knew nothing about the DevConnections lunch because she chose not to attend it.

It’s OK to have a conversation about women in this industry. Samantha chose to make herself part of that conversation. But that conversation must be on what’s real, not on this persistent crazy fantasy that there is a cadre of harpies somewhere.

Trust me, almost every woman in this industry is, like Samantha, just out there working hard, bringing a unique set of skills and capabilities to the problem at hand, and thinking about how to build the career she wants in a very crazy, tough, fun industry.

Module 2 High Points: Portable Class Libraries

2013-04-03T14:53:00Z

I’m continuing to channel how excited I am about my Pluralsight course “What’s New in .NET 4.5” into a series of blog posts with the most important thing(s) in each module. Sure, I won’t mind if these posts inspire you to watch my course, but I’m also doing this so folks that can’t watch my course can still get the most important information.

Module 2: Changes to the Core Framework

There is a whole lot of information in this module, and I might come back to the most important thing in each clip. But for right now, I’m going to maintain discipline and focus on the single most important thing, which has two parts.

That would be the changes in how we deliver applications - how libraries are arranged and how MSIL becomes native code on the target machine. I’ll focus on how libraries are arranged, with just a smidgen on native code creation because it deserves a dedicated post.

Portable Class Libraries

You might have heard about Portable Class Libraries. It’s a new type of class library you can create that will run on the platforms you choose. Right, that’s platformS, plural. In the box you’ve got .NET main framework, Silverlight, XBox, Windows Store and Phone. Online, you’ve got more, including Azure and updates to other platforms.

In these libraries – these DLLs – you can only do things that work across all the selected platforms – the limited intersection of behavior. You’re not going to write your entire application this way, but you can create key libraries with business rules, calculations, maybe service access, maybe View Models – you get the idea. This, of course, directly useful. It also causes both you and Microsoft to rethink the concept of a DLL.

Your Libraries

Using Portable Class Libraries will force you It will instill new discipline in your designs, and I’d encourage you to begin moving everything possible into Portable Class Libraries just for this reason.

Isolated designs have been on our whiteboards for years - like View Models without any UI artifacts. But enforcement was by .NET libraries – and they were designed for many reasons other than correctly dissecting your code. No one that created reflection had a clue that it would look fundamentally different in a Windows Store application.

Visual Studio provides the appropriate IntelliSense and the compiler structures the correct libraries. We coders work organically. There are things we learn to do reflexively, and you want the classes and methods you reach for to be the right ones – generally that means the techniques with the broadest reach. As you learn what works within your Portable Class Libraries, you’ll learn what works across multiple platforms.

I’ll warn you that the jury isn’t entirely in on some critical details, such as using async across some of the different platforms, but many core features work flawlessly today, and the others are sorting themselves out.

Microsoft Libraries

Prior to .NET 4.5, the .NET libraries were fairly large units and completely different versions were created for alternate platforms. Just ask a phone developer how painful this pattern was as new sets of redesigned libraries reflected changes in how .NET was interpreted for the platform.

Starting with apps targeting .NET 4.5, there’s a new approach to core assemblies. This reflects platform differences, such as how local storage works, and isolates commonalities. Sometimes, such as the new Zip libraries in .NET 4.5, libraries can be designed with portability in mind.

It doesn’t make sense to restructure legacy assemblies to meet today’s vision, because today’s arrangement will be tomorrow’s legacy. Instead a huge effort behind the scenes created smaller leaner libraries that can be pulled together, and a redirect system that means you no longer care where any piece of functionality resides.

You can see this in Object Browser. View Containers to show the assemblies (from the gear for settings) and select “Portable Class Subset” (not legacy) from the dropdown. Now open mscorlib. Huh!!! It’s empty. That’s a bit of a surprise.

Now open System.Runtime – which is one of the many libraries that didn’t previously exist. It’s got all that mscorlib stuff. What you need at runtime will be there – but in an assembly location that’s platform dependent.

Reflection

Nowhere is the importance of PCL more evident than with the newly designed reflection. It needed an overhaul. It sits at a critical junction of many other things – often causes performance problems of design compromise to avoid performance issues. For example, if you ask for the members of a type, assemblies containing all base types must be loaded. Also, GetMembers and its siblings have horrendous enum dependent overloads to help you filter the results.

Microsoft redesigned reflection for Windows Store applications. I’ll skip the details, but the GetMembers method is replaced with a DeclaredMembers property that returns an IEnumerable you can party on with LINQ. It doesn’t load any base class assemblies – if you want that, walk the tree so you understand what’s happening. The team also split the name of the type separate from all other functionality. The name is often enough and avoids loading even the class’s assembly.

This quick sketch of the massive change lets me illustrate why you want to move reflection based code into PCL projects.

.NET main framework projects need to support the old and new reflection approach. Instead of ditching the old stuff and creating a new namespace, they extended existing reflection to include the new features. I’ll leave it to the video to explain the inheritance hierarchy sleight of hand that let’s this happen. But the resulting classes have all the features of the old and new reflection approaches.

While I agree with this decision to allow smooth transition of existing reflection code with no breaking changes, I think it makes it nearly impossible to learn and use the new reflection approach – unless you create a PCL targeting main framework and Windows Store apps and do as much of your reflection work as possible in this assembly.

You’re already doing all your reflection in utility methods – right? No? Well, then this is also a moment for reflection, er, um, no, um, meditation, contemplation, deliberation, musing, rumination on the nature of an evolving framework and how to structure code to survive this change. That’s more posts, and I’ll get to them, but for now, reflection of your poster child of constructive change you’ll need to roll with.

JIT and NGen

It’s a separate blog post series, but I just can’t talk about this module without talking about JIT and NGetn. Your actual delivery is changing. There are now six, or is it seven, different ways IL can turn into native code on your target machine. It’s a pretty big set of changes, and I promise a blog post that cuts through some of the detail I hit in the video to more simply explain how to choose your approach. But don’t worry, for most people, most of the time plain old JIT remains the best approach (maybe with a little chocolate sprinkles).

Core Library Changes

Does my focus on the library creation and deployment mean that there weren’t any meaningful changes to the libraries themselves – new classes and methods? No, it doesn’t mean that at all.

There were a lot of changes to the core frameworks, and I hope to come back and give the most important couple of items from each clip in this module – changes to reflection, big arrays, console improvements, and, most exciting of all, real Zip support. These are great improvements, but none of them stand out as changing your development the way PCL does.

Module 1 High Points – Side by Side Implications

2013-03-29T14:14:00Z

I’m really excited about my new “What’s New in .NET 4.5” course on Pluralsight.

There’s more information in the course than I could stuff into my blog in a year, but I want to cover a few high points here. I wrote the course as “What I want every coder and manager to know about this release,” but I know you won’t all get a chance to watch it. So, I’ll cover what I can here, starting with a series of short posts with the most important point, or maybe two, in each of the eight modules.

Module 1 – Introduction

Yes, the introduction is more than an agenda slide J

As an in-place release, there are two versions of the .NET 4 libraries – no, wait three versions – and probably more in the future. That’s right, I said the .NET 4 libraries – it doesn’t matter whether your targeting .NET 4.0 or 4.5. I know that sounds a little crazy, but I’m afraid we’re going to have to get used to the craziness.

You probably don’t control the version of the .NET framework that’s running in production. Another application installation, or the user, or an operating system upgrade (Windows 8 or Server 2012), or at some future point Windows Update could upgrade a target computer to a new version of .NET 4 without you touching your deployed application in any way.

That should scare you, but it’s part of the brave new world. Microsoft is tooling itself for fast incremental releases, led by the fantastic advancements in the Azure space. There’s a good side of this and a bad side of this, and in the end I’m not sure it matters very much what I think.

So, you’ve got to learn about this release, whether or not you intend to target .NET 4.5 in the foreseeable future. And we need to ferret out ways for ongoing validation of our working systems – validated algorithms, in-place production testing, and widespread use of tracing (oh wait! that’s module 3 on ETW support).

I said there were three, versions of the .NET 4.0 framework in the wild – there are probably more with hot fixes, but these are the three you need to know about.

- .NET 4.0 released with VS 2010 (4.0.30319.1)

- .NET 4.5 released with VS 2012, regardless of target platform (4.0.30319.17929)

o Please don’t run this version this pre-January 2013 updates version if you can help it

o You may not be able to ensure your user’s install this recommended upgrade

o There’s a corresponding security update that is separate and required

- .NET 4.5 reliability (and security) update released January 8, 2013 (4.0.30319.18033)

If you’re not thoughtful, you may be testing against a different version of the framework than the one your users are running.

On a particular machine, you can determine whether the updates are installed through Windows Update history, the registry, or the version number on something like mscorlib.dll in the GAC (oh wait! that’s module 8 on breaking changes). You can also test for the existence of the type System.ReflectionContext if you want to know whether you’re working with a version above the VS 2010 libraries (4.0.30319.1). Test for a type, not a member (reflection considerations are in module 2 on the core framework changes) and not the specific version number, which might be fragile going forward.

There are at least four ways the new version of .NET will affect your code:

- When new libraries are installed in production (what I’m talking about in this post)

- When you recompile with the VS 2012 compilers (regardless of your target version)

- When you target .NET 4.5 for its awesome new features

- When you rerun custom tools

- When a computer you exchange data with upgrades libraries

The five point survival guide is test, test, test, test, test, test. And that’s regardless of when you plan to explicitly target .NET 4.5.

Overall .NET 4.5 is awesome and the compatibility of the new libraries is good. But, if your one of the unlucky ones that encounter a problem, the probabilities don’t matter at all.

Whether it’s through my course or other venues – if you’re responsible for production code, you really need to learn about .NET 4.5 and start considering how you’re going to accommodate the new fast moving cycles.

DevIntersection

2013-03-08T14:22:41Z

I thought I should post a status after being so quiet on Twtiter and my blog.

I had a really fun, intense time putting together my next Pluralsight video. It’s delayed for a technical screw-up on my part, but it should be up in the next week or two.

Upcoming, I’ll be at DevIntersection (www.Devintersection.com). I think it’s going to be an awesome show – check out the line- up of speakers. There’s also a great pre/post con deal – registering for the conference and pre or post con gets you a tablet as well! And if you use the discount code DOLLARD (how easy is that to remember) you’ll get $50 off!

If you haven’t heard of DevIntersection, that’s because it’s a new conference. But don’t worry, it will be smooth and professionally run with leadership and staff that are some of the most experienced around in presenting conferences for developers

I’ll be teaching you things you don’t know or have forgotten about the core .NET framework in a pre-conference workshop titled “Getting the Most from the .NET Framwork”. Half the day is fast paced puzzle format with plenty of surprises for even the most experienced .NET programmer. I get asked whether the details matter – I pick puzzles because they affect what code runs, the result of calculations, might have significant performance implications, and help you better understand the framework. This understanding helps you read code, and it helps you right code with minimal surprises – bugs based on surprises are hard to find!

In the afternoon I’ll move through potentially challenging areas of the framework improving your mental models of how and why things work. I’ll teach the why and how, not demonstrate the how-to. You need both, but this day is dedicated to making you a smarter, more robust programmer.

If you live in Vegas or can get there easily, you can register separately for pre and post conferences – but then you’ll miss the show!

The next conference I’m scheduled for is DevTeach, May 37-31 outside Toronto. I’m looking forward to celebrating DevTeach’s 10^th anniversary.

Workshop

2012-12-05T15:56:16Z

I’m extending my popular “Getting Geeky” series to a full day workshop at DevIntersection on Dec 13. I’ve struggled a bit naming and describing this series – it’s called “Better Coding: Stop Coping, Start Comprehending” at DevIntersection. My goal is to dive into the important aspects of the .NET framework – both old and new. To expose you to, or remind you of, details in the context of why the .NET framework behaves the way it does - from details about integer math, inference and overloads to the implications of MEF and Async on your architecture. It’s very fast paced and focuses on the things that I think you need to know that many people, even many very, very smart programmers don’t know.

I’ll do this workshop with a little theory and a lot of code “puzzles.” Unit tests where the audience gets to predict which asserts that will pass and get immediate feedback directly with the code. You’ll also get my puzzles code to experiment with later. It’s a fun way to stay engaged – while it’s obviously important to know what code will run and what the outcome will be, zillion of details can get scattered and a bit dry without some underlying theory and the code itself teaching you.

I love getting excited about new features – but I also love making a fun time of understanding what’s in the core. I’d love to see you at my workshop at DevIntersection. I’m also available to give this workshop in a one or two day forma, with or without adjacent mentoring and team coaching.

You can sign up for DevIntersection, or the workshop here.

Here’s some recent feedback from the short form of this talk:

“If this presentation had been a job interview, I would have failed. That is what made it a great presentation. The most dangerous facts are the ones we are sure we know that aren't true. Without every actually having looked into it, I expected the default behavior of .NET to be to automatically detect arithmetic overflows, only to have Kathleen teach me that it is not the default for integer math and is not even an option for floating-point math.

In about an hour and a half there were a dozen other puzzles about .NET basics, teaching me that I do not fully grasp overloads, type inference, generics, and other key framework concepts. I would have skipped lambdas and closures myself, as they have done nothing but make my head hurt since I first read about LISP in 1975. However Kathleen rightly discussed them as they are necessary to understand her discussion of LINQ, which is useful.” - Martin Buchanan

Your talk on Monday was absolutely your best ever – you really have a special touch that you have been refining for quite a while and you could not have been better – very impressive!

My members really liked it – nothing but outstanding reviews. Your enthusiasm was infectious (in a good way) and it showed with the tremendous interaction. Your professional animated talk and engaging personality truly highlighted your inner desire to find areas of knowledge that you could pass onto others – helping them become better at what they do. I hold my members in high regard and you continued to foster an environment which makes it all worthwhile. – Chris Wallace, president Denver User Group

(BTW, the Denver UG has a special place in my heart because I have been occasionally speaking there for over 15 years)

Slides and code for Denver Visual Studio User Group Talk

2012-11-27T22:25:00Z

I had a great time last night at the Denver Visual Studio User Group. The crowd was super engaged and on top of the code tricks/surprises I tried to throw at them.

Thanks again to Chris for his long term leadership of the group!

Slides and code attached.

Why You Should Come to DevIntersection

2012-11-18T17:10:04Z

DevIntersection is going to be an awesome conference. It’s right around the corner, so get to work convincing your boss to let you come. Here are just a couple of reasons you should come.

- You get a Windows 8 Tablet. Yep. That’s right, a Windows 8 Tablet! Register by Nov 20 for that!

- It’s in Vegas a week that has traditionally low airfares

- $65 room rates and the MGM Grand, so your overall cost will be relatively low.

- The MGM has just been renovated, so the facilities should be great.

- Richard Campbell is the force behind this show, so you know it will be a bit irreverent, casual and absolutely stuffed full of great information

- There’s an amazing list of speakers

- Look for a fantastic blend of info direct from Microsoft and some of the best independent speakers to go way beyond the Microsoft party line.

- Keynotes by the Scott Guthrie, Steve Fox, and the Visual Studio Team

- It’s your last chance effectively use any leftover training and travel funds in calendar 2012

- Did I mention that everyone who registers by Nov 20 gets a Windows 8 Tablet?

Abstracts for the show are under “Sessions” at DevIntersection . My talks are:

Deeper into Async – I’ll explain async in .NET 4.5 and show techniques to integrate timeouts, cancellation and exceptions into your async apps. (There is a mistake in the heading, in 75 minutes, I will focus on single thread async – this is NOT a multi-thread talk, I’ll work to get this fixed)

Visual Studio 2012 Tips – I’ll show you ways to improve your navigation, editing and searching techniques.

Managed Extensibility Framework in .NET 4.5 – I’m really excited to show you the next version of MEF with resolution of open generics, flexible container creation and inference and improved diagnostics. This will start with an introduction to MEF so it’s definitely not just for MEF geeks.

You should also come to my post conference workshop called Better Coding: Stop Coping, Start Comprehending.

I’m becoming increasingly passionate about people learning or relearning core concepts of the framework. In general, it’s consistent, and if you understand what’s happening under the hood you can predict what it will. You can get your hands on a lot of material on the main libraries. That’s great, but, as I’ve gone around the country doing talks, I see a dropping level of knowledge about the core framework itself – the type system, the languages, the fundamentals of why .NET works the way it does. And I’ve seen this in folks that have been in .NET since the early betas because it’s been a really long time since .NET kicked off.

There’s the basics - we still need to understand nuances of the heap and stack, overloads, evil static constructors, the multiple meanings of equals, attributes and such things. And there are the things that have evolved our thinking about code – generics, lambda expressions, LINQ and Dependency Injection. And there’s the new stuff – async, simpler parallel processing, code info and event sourcing. Whew! It’ pretty overwhelming unless you have a mental model that aligns with the consistency underlying the framework. This day is absolutely stuffed full of information to make you better at writing .NET code.

I teach this with a fun unit test “puzzle” format where the audience collaborating to select from multiple commented assert options. I’ll ask you to think as well as listen, and sometimes you’ll get fellow students explanations as well as mine for the critical question of why something works the way it does. We might do a skit involving throwing Snickers bars, and I’ll integrate Visual Studio tricks, so when I write code for you, I’ll show you some pretty cool things along the way.

I hope you’ll sign up for DevIntersection, get your new Tablet and sign up for my post conference workshop as well!

Why is My Pluralsight Course in Visual Studio 2010?

2012-11-11T17:48:53Z

There were a couple of tweets when my Pluralsight Visual Studio 2010 Tricks released pointing out that Visual Studio 2012 has been released. I actually had noticed the Visual Studio 2012 release. So, why the course in 2010?

I could give a lot of answers. There are currently people working in both versions and most Visual Studio tricks work in Visual Studio 2012 and such things. But the truth is I massively underestimated the amount of time I’d spend on the course – an order of magnitude in the number of hours. I optimistically anticipated the course would release before 2012. That didn’t work out. So, the more interesting question is why I didn’t start over. The core issues – keystroke shortcuts, columns selection, selection anchors, settings, and a boatload of things I covered are the same for VS 2010 and 2012.

There have been significant changes in Find and of course there are a boatload of new features. I do talks at conferences and user groups about the new features and I’m totally stoked about the new version. But I think to do the kind of course I did takes a little time. The VS 2010 Tricks course, and the course I hope to do in a few months on VS 2012 aren’t a list of Tip #1, Tip #2, etc. It’s a holistic view of how to smoothly leverage the environment where the rough spots and some of the bugs are and how to work around them. That’s going to take some time to work out. In the meantime, you can get an overview of the new features in Kate Gregory’s course Introduction to Visual Studio 2012.

Why did the course require so much work? Video was a new format to me, and I thought a lot more of my audio experience would translate to. And I want the course to move very fast. In a tricks course, and probably any skills course, there’s a chunk you already know, a chunk you’re never going to use, and a chunk that make it all worthwhile. I want to get you to whichever nuggets of gold you’re going to find in the course as quickly as possible. And I want to keep you engaged – so I worked to add the occasionally, hopefully humorous moment. I learned an incredible amount. My future videos will be better for what I learned, in the end, it was time to tie it up, imperfections and all, and get it out to you. Hopefully you’ll enjoy it – a clip a day will gradually make you a more efficient coder.

And I hope you’ll keep an eye out for the next video I do!

Plain Old Objects and MEF

2012-10-11T11:08:00Z

After my MEF presentation at the Hampton Roads .NET User Group someone asked me about creating objects like customers and invoices via MEF. I gave an overly quick answer to a really good question.

A lot of the IoC history involves using dependency injection for services. This is great partly because it's a framework to isolate plain old objects from services, and services from each other. Like many of the techniques we've adopted in the agile timeframe, it's not just what the technique does for us, but what the technique does to us. That's the quick answer I gave.

But, we can go further to fully composed systems. Fully composed systems have offered mind boggling benefits in some places they've been tried, and they haven't been tried in very many places yet. This is why I have such a high fascination with NetKernel and the work people like Randy Kahle (@RandyKahle) and Brian Sletten (@bsletten) are doing. And that work is similar to work Juval Lowy and I have talked about for a number of years.

However, fully composed systems with MEF, and I assume other DI tools (although I'll be happy to be proven wrong) are hard. Without the infrastructure of something like NetKernel there's a fair amount of work to do, and without the caching benefits of NetKernel it's going to be tough to justify. It’s hard because everything needs an interface. Everything. And even if you generate the interfaces and plain objects, the level of infrastructure ceremony gets very unwieldy.. At least that's my experience from using MEF to wrap everything (yes, everything) in interfaces, in order to create a fully composed MEF 1.0 system.

We could go a slightly different direction. Put everything into the container, but place plain old objects in the container as their own type, rather than via an interface. Plain old objects in this sense are objects that we can't imagine a scenario where they'll be reused and they have a unique, and generally multi-valued interface. A customer or invoice POCO would be examples.

Placing these objects into the container offers the immediate benefit of guaranteeing their usage is isolated We take advantage of what DI does to us, not just for us..

And if we use inference in MEF 2.0 (.NET 4.5), and probably configuration techniques with other IoC containers, we can stick another object in if we have a later reason to do it.

But here's where strong typing bites us. Any new class that ever replaces that plain old object (the customer or invoice) has to be assignable to that class. That means it has to be that class or a class that derives from it. I'm still hanging on to the strong typing life boat because I still feel that without it I'm in a North Atlantic storm. For big systems, I think that's still true, and while I put a lot of thought into making big systems into smaller systems, non-typed based DI is still a jump into icy water for me.

With the plain object in the container under its own type, if I get blindsided with a requirement that just doesn't fit I can manage, I just have to write a wrapper for the non-derived object and the wrapper has to derive from the expected type. Ugly, but workable.

What I want to do is experiment with strongly typed systems with generated interfaces. I've already done this with traditional generation, and I want a solution that is cleaner than that. I don't have the syntax worked out, but imagine that we never create the interface for our plain old object, we just tell the system to do it. The container uses the interface, all using objects request the object by its interface, and we humans can ignore it.

Until the day the plain old object needs attention. On that day, we make the interface explicit and do whatever we need to do.

But with the versions of .NET we have today, we can't build this.

Formatting Replace Output

2012-09-16T00:48:26Z

This post applies to Visual Studio 2010. I'll do another post on Visual Studio 2012.

I’ll show you how to control the output of Replace in Files. To see where this is going, here’s before and after pictures.

Here’s the view before the change. Note that I scrolled right to show the end of the line, and if the names of the directories were different lengths, this would not line up at all. This is about the best this will ever look:

You control the output after the change. Here's one possiblity:

Personal Note: On rare occasions you get to find something that isn’t reported elsewhere, making you feel like you’ve found something no one else in the world knows – although obviously this isn’t a new continent and I’m not the very first person to know how to alter the output of Replace in Files. Still finding something that isn't documented yet on the web is pretty exciting.

Find Format

I love Sara Ford and Zain Naboulsi. They’ve posted boatloads of tips on Visual Studio over the years and they've got a great tips and tricks book. One of the great features that Sara introduced us to in 2006 is formatting the output of Find in Files – you can find that post here .

As Sara explained, the output of the find results window is controlled by a registry key called “Find result format.” It’s a rather arcane syntax that creates a string output for each line, you can’t control the output by columns except with tabs, but you can create much more usable output than the default. I’ll let you check out Sara’s article for details.

Replace in Files

The Visual Studio Replace in Files feature is cool – you can control the scope of the replacement better than Quick Replace, you can control whether files are left open, and you get a list of all the changes made. That list of changes is a great feature. It’s so great that you might even want to use it if you are just making replacements in a single file.

You’ll find Replace in Files if you drop down the Replace combo box at the top of the Find dialog. You can select al of the standard scopes, as well as selecting specific folders by right clicking the three dots to the right of the combo box.

When you select Fnd All, Visual Studio lists of the changes that were made, in the Find Results window. If you don’t like the changes, and you left files open, you can undo all the changes with a single Ctl Z.

Replace Output Format

I was really disappointed that the Find result format did not affect the output of Replace in Files. The oversight surprised me, so I decided to take a shot at creating a registry key named "Replace result format." I wasn't optimistic, but voila' it worked!!!

Note: You can screw up Visual Studio, or even your computer if you mess up your registry. Be careful out there.

To make this change, open RegEdit and find the key

HKEY_CURRENT_USER/Software/Microsoft/VisualStudio/10.0/Find

Add a string value named "Replace results format" (no quotes), modify, and add your preferred format.

Here’s a summary of the important format options for Find.

All these format options work in Replace as well. In Replace, and there are some additional options that don't make much sense in Find.

In Sara’s post, she refers to $t, $T, and $s as matched values. This probably seems picky, but for clarity I want to point out that it's not the matched value, but the replaced value that's displayed. Obviously for the Find result format key it does not matter, but for the Replace result key there are different. You actually can’t get the matched values, which is an incredible shame.

My Favorite Formats

$l\t$c\t$f$e:\t$s\r\n is line, column, file with extension and first line of replacement

$l\t$c\t$f$e:\t$0\t$s\r\n is line, column, file with extension, replaced value and first line of replacement

$l\t$c\t($g)\t$f$e:\t$0\t$s\r\n is line, column, replacement length, file with extension, replacement value and first line of replacement:

Enjoy creating custom formats for Replace in Files as well as Find in Files!

Breaking into the Visual Studio .SOU File

2012-08-21T17:22:34Z

I’ll probably need to do this again one day, so I want to record how I did it…and it might help someone…

I wanted to check whether an absolute or relative file path was saved for a particular thing in the .SOU file. But, Notepad displays garbage when you force it to open a .SOU file.

Instead I opened another copy of Visual Studio 2010 (not a copy where this solution was open, tried that, it didn’t work). I created a new solution folder, and dragged the .SOU file into it.

I could not drag it onto the document surface, because someplace along the way I picked up a file association with Notepad – so Visual Studio was just one more mechanism to do the useless.

I selected Open With from the Right Click context menu and selected the binary editor.

Find did not work for me. I can think of a few possible reasons.

So, I selected from the first readable text in the binary editor to somewhere near the last readable text and did a normal Ctl-C copy. In other words, I used the binary editor to chop off the beginning and end of the file, and to put something sufficiently useful into the clipboard buffer. Notepad cooperated in displaying the text retrieved from the clipboard buffer with a normal Ctl-V paste.

This file is still a mess, not usable for any normal exploration. However, I could confirm that the file name I was interested in was only stored in absolute, not relative form.

Microsoft, please, pretty, pretty, please, pretty, pretty, pretty, pretty, pretty please can we get readable formats for .sou and .user files?

To “as” or not to “as”

2012-08-12T18:37:00Z

Iris Classon is asking and finding answers for “stupid” questions on her blog. First of all, they are definitely not stupid questions. There are a lot of nuances of .NET that slip out of our daily thinking. When I first started my Getting Geeky with the .NET Framework series I’d ask really hot coders basic questions – things that affect how code runs – and the results were not stellar. So, first, three cheers for Iris’s project.

Today’s question was “How should I do casting in C#? Should I use the prefix cast or the as-cast?” She’s got some good input that I suggest you read first. I also felt that the discussion left out a significant factor - debugging.

If the value resulting from the cast really should not be null, the code becomes unstable or incorrect at the point of the cast. Period. With the prefix cast, application state clearly becomes incorrect at that point because an exception occurs. With the “as” cast, the application state still becomes incorrect at that point, you just don’t know it. If the value should not be null, you’ll get a null exception, or possibly failure of a Requires clause if you’re using code contracts somewhere, sometime later in application execution.

One of the things that makes hard bugs hard is when there is a disconnect in time or space between the cause and the symptom. Time is time, space is lines of code, assembly placement, etc. Code can be written to minimize these disconnects. One of the ways to do that is to fail quickly. When application state becomes incorrect, yell about it immediately and rarely continue with the application in an invalid state. A null-reference exception at an unexpected time just makes code more difficult to debug.

Eric Lippert’s quote short-cutted the idea of what happens next. He’s quoted as saying that a prefixing cast failure requests, “then please crash the program.” That would be much better put as “then please do not continue the current operation.” Our programs need never crash in the sense of blue screen ugly death. Exception handling is a mechanism for recovering to a valid state, with the capacity to communicate failure to interested parties like the user and system logs.

So, use the “as” cast only when the resulting null does not make the application state incorrect, or you have an immediate and adjacent test that you prefer to make the application state correct or perform different exception management. For example, you might want to add a specific error message if the invalid cast indicates a particular type of problem.

I think the prefixing cast should be the “go to” cast for .NET – the one you use when you haven’t thought through the implications of the null value to the remainder of your program.

Build/DevConnections Scheduling Conflict

2012-08-01T16:36:24Z

Since Microsoft scheduled Build on top of DevConnections, I’ve had people ask which conference they should go to. I’ll start by admitting my bias. I haven’t missed speaking at a major DevConnections show for six or seven years, and if you come to DevConnections, you can come see my talks!

But biased or not, I think the DevConnections/Build decision is a no-brainer…they are very different events. This is a quick list off the top of my head with no discussion with any marketing people at either event.

- Based on history, the Build content will have good technical content, but be planned for Microsoft’s marketing convenience

- Build will focus on future products

- Build talks and speaker list may not be public until the last minute

- Build speakers will be from Microsoft and might be constrained in what they can say

- Build sessions will probably be recorded so you can see them in the future

- Build may help you make human connections inside Microsoft to get your opinions heard

- Build will probably sell out in minutes, possibly seconds

- Build attendees might get cool hardware – maybe a new Surface

- DevConnections will include a Microsoft day, presumably with future focus, that day may be driven by the same marketing as Build

- DevConnections will feature many high level Microsoft speakers, including Scott Guthrie

- DevConnections has two days of independent content with a long track record of healthy skepticism of Microsoft stuff

- DevConnections speaker and abstract lists (day 2 and 3) are public right now

- DevConnections speakers (day 2 and 3) are independent industry experts, I’m humbled to be in such company

- DevConnections is focused on what devs need today and tomorrow, not next year

- DevConnections has an extremely wide array of topics with seven concurrent conferences – you have access to all

- DevConnections makes a lot of sense for teams that need to bring several members and have them learning different things (data, web and core, for example)

- DevConnections features pre and post conference workshops (for additional fee)

- DevConnections is larger with more opportunity to network with real devs and won’t sell out anytime soon

- DevConnections talks are not recorded – you’ve got to be there (all slide decks are available to all attendees)

- DevConnections has amazing independent speakers that are the best in their field and focus on communicating complex ideas – Kimberly Tripp, Juval Lowy, Ward Bell, Dino Esposito, Julie Lerman, and Mark Minasi represent incredible breadth, and are just the tip of the iceberg – really, go look at the speaker list (you have to look separately for each co-located conference)

- I hate Las Vegas, but the weather is better than Seattle in November

- The Bellagio is nice and if you can’t get your company to spring for it, you can get a deal at many hotels with relatively easy access

- Las Vegas is one of the easiest places to fly to from anywhere (except Fairbanks) and you can lose all your spending money before you even leave the airport

- OK, the taxi queues are definitely better in Seattle, but the venue is closer and access easier in Las Vegas

If you think I’ve missed something for either event, let me know. I’ll try to approve comments quickly.

High Park Fire

2012-07-31T15:06:18Z

I haven’t been able to follow up on the fire, because it’s been too hard to catch it.

From my near hysteria on the phone with a friend the first day when I was watching the plume and knowing my sister would be out there with it. To the shock of seeing the fire walking down the hill to my Colorado home. To what it means to be evacuated. To listening in on emergency services to hear Carol’s voice and know she was OK. To hearing the radio traffic as Poudre Fire Authority fought for Don’s. To be guessing what “happy dance” meant. To know that there were so many houses that were still in danger ten days in. To the pop, pop, pop of people I knew in so many different ways… Louise lost her house, Mark lost his house, Larry lost his house and shop, Joe lost his house and his entire horse set up. To hearing that my best friend lost her house. To coming home to ash and the black and the fire line right there next to the house. To the map where the east fire line jogs west just north of CO 14. That’s the driveway, that’s where the fire goes around the house. To knowing there are people going home to the middle of the ash. To the driving east with my son on a prescheduled trip two weeks in and someplace in Kansas finally not seeing smoke.

I can’t explain all that. Someone helped my sister tell the bigger story, the real heroes. Watch it.

This isn’t over. This is the beginning. There are houses and lives to rebuild.

Lifting ForEach, Breaking Change in Visual Studio 2012

2012-07-03T15:15:00Z

This post is updated due to the STUPID error I originally made in the last code sample. Thanks to the folks that pointed it out!

Also, I neglected to thank Adil Mughal for grabbing the ReSharper warnng text for me.

There’s a breaking change you should know about in Visual Studio 2012. In case you have a short attention span, aka have a life, I’ll give you the punch line first. The behavior of closures has changed in the specific instance of a lambda expression.

Good news: You aren’t writing the affected code on purpose, or if you are I honestly want to know why

Bad news: I don’t think anyone can guarantee their code doesn’t contain the issue

Good news: It’s a side case, the affected code probably isn’t there

Bad news: If it is in your program, its behavior will change when compiled with VS 2012

Good news: It probably won’t be too bad if the behavior changes

Bad news: The change symptom might be obtuse or bizarre

Good news: If you use VB or ReSharper there’s a warning and you just need to look for it

Bad news: If you’re in C# there’s no warning

Good news: You can download ReSharper’s 30 day free trial and run it against all of your code in 30 days (yes, I asked before posting this suggestion)

Observe the Change

Run this code in a console application in Visual Studio 2010. You might want to predict the result before continuing with the blog post:

class Program
{
    static void Main(string[] args)
    {
        ClosuresForEachWithLambda();
        Console.Read();
    }

    public static void ClosuresForEachWithLambda()
    {
        var actions = new List<Action>();
        var list = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
        foreach (var i in list)
        { actions.Add(() => Console.WriteLine(i)); }

        foreach (var i in actions)
        { i(); }
    }

}

Or the identical code for Visual Basic

Option Strict On

Module Main

    Sub Main()
        ClosuresForEachWithLambda()
        Console.Read()
    End Sub

    Public Sub ClosuresForEachWithLambda()
        Dim actions = New List(Of Action)()
        Dim list = New Int16() {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
        For Each i In list
            actions.Add(Sub() Console.WriteLine(i))
        Next

        For Each i In actions
            i()
        Next
    End Sub

End Module

The Answer and the Explanation

While you might expect this code to print 0,1,2,3, etc, it actually prints 9,9,9,9, etc.

When variables are used in a lambda expression, the actual variable goes along for the ride. Not a copy, not the value but the actual variable. This is called a closure and is essential to you getting the behavior you expect at many other points in .NET. You can also find examples in this blog entry by Frans Bouma and a different example by Dmitri Nesteruk.

This is a significant enough issue that both Visual Basic and ReSharper issue a warning. C# without ReSharper does not issue a warningThe Visual Basic warning is

Warning

Using the iteration variable in a lambda expression may have unexpected results. Instead, create a local variable within the loop and assign it the value of the iteration variable.

The ReSharper warning is

Access to modified closure

The Visual Studio 2012 Change

When a lambda expression uses the looping variable of a for each loop in either Visual Basic or C#, the Visual Studio 2012 compiler creates a new variable scoped to the loop and assigns the value of the looping variable to this variable. Logically it’s the same as:

public static void ClosuresForEachWithLambda()
{
    var actions = new List<Action>();
    var list = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    foreach (var i in list)
    {
        // Changes are here
        var x = i;
        actions.Add(() => Console.WriteLine(x));
        // End changes
    }

    foreach (var i in actions)
    { i(); }
}

Since the new variable is scoped to the loop, there’s a new copy for every iteration of the loop. The original code compiled in Visual Studio 2012 prints 0,1,2,3… Try it!

Why this is a Really Good Thing to Change

I’ve been showing this code at user group presentations around the country and taken a few other opportunities to put this code in front of .NET developers - some of them really good .NET developers - and asking what the code would do.

The most common response is a few people in the room get it after about a minute. Sometimes, no one gets it. It’s exceedingly rare that anyone will have an immediate knee jerk response that it will print all nines. I get boatloads of “I should have seen that!” and very few “I saw it right away!” And, the very fact I am asking the question creates a context that the code probably doesn’t do what you’d expect and I made it as obvious as I possibly could. Your code is going to be a list of customers or invoices or something else. The vast majority of .NET developers do not expect the VS 2010 result, even though it is technically correct.

The async features of Visual Studio 2012 will create lambda expressions for you, and you will be much more likely to create lists of lambda expressions for simultaneous execution. Your ability to see this issue in your code gets significantly tougher in some VS 2012 scenarios. It was time to make this change.

It would have been nice if this had been an error from the beginning of lambda usage in .NET. But that didn’t happen and adding this as an error would have been a different kind of breaking change. For better or worse, the automatic fix won over adding an error or warning.

Is it a big deal?

I get asked a lot whether this is a big deal – sometimes even by people that are responsible for a code base.

It’s probably not a big deal in your code. The chances are excellent that you do not have code that uses a looping variable in a lambda expression. If you do, it’s probably a mistake – that’s why VB and ReSharper issue a warning. And it’s possible that any change in behavior will either be immensely obvious and perhaps trigger a test failure, or be so subtle that it never breaks your code at all.

But these are the wrong question to ask about a breaking change. The right question is “Can you guarantee that this does not exist anywhere in the code bases you are responsible for?” That’s the bar for a breaking change – can I guarantee I know how it affects me. The only way to do that is to run a tool that looks for the problem – check for the Visual Basic warning or run ReSharper.

I have had only one person say they were extremely confident that their unit tests would catch this change. I believe they are wrong. This is a side case that can give extremely unexpected behavior. It’s not a change I’d trust unit tests to find.

What’s Not Changed

This change happened because it can be very difficult to see the issue in a for each loop. It wasn’t done lightly and the teams decided to do the change in as narrow a scope as possible. That means the change was not made to for loops in either Visual Basic or C#. The following code returns 10,10,10, etc with both the VS 2012 and VS 2010 compilers.

public static void ClosuresForWithLambda()
{
    var x = new List<Action>();
    for (int i = 0; i < 10; i++)
    { x.Add(() => Console.WriteLine(i)); }

    foreach (var j in x)
    { j(); }
}

Or for VB

Public Sub ClosuresForWithLambda()
     Dim x = New List(Of Action)()
     For i = 0 To 9
         x.Add(Sub() Console.WriteLine(i))
     Next

     For Each j In x
         j()
     Next
End Sub

The Critical Footnote

Any breaking compiler changes are a big deal. They aren’t such a big deal if we know about them, they are side cases and the new behavior is improved. The Visual Studio teams have announced that they are working to replace the compilers in a future version of Visual Studio. The current compilers are old and it seems highly unlikely that they can be rewritten without breaking changes. We can handle some breaking changes as long as the issues can be found with tools – specifically we can identify code that is clean of known behavior changes because of compiler changes. One of the reasons I want the community talking about this breaking change is that we need to establish expectations for all future breaking changes. So, talk about it. Run ReSharper. Tell your friends.!

INotifyPropertyChanged Implementation for VS2012

2012-06-30T21:57:00Z

I told some folks at the East Tennessee .NET UG (ETNUG, which was adorably put on the reservation board at the after meeting bar as “Eatnug”) meeting in Knoxville that I would post info on a .NET 4.5 version of INotifyPropertyChanged that used CallerMemberName. I also said I wanted to reference other people rather than making up on my own because I’d rather post something already vetted.

CallerMemberName is a new feature of .NET 4.5 that lets you access the name of the thing that called the current method. It’s implemented by adding an attribute on an optional parameter:

public void Foo([CallerMemberName] string callerMemberName = null)

The CallerMemberName attribute signals that the caller parameter should contain the name of the calling method, to be filled in automatically if the calling code doesn’t pass a value. Since it’s an optional value, the calling code doesn’t need to pass a value, and should only pass one when chaining the “real” caller member name. Unfortunately, Intellisense doesn’t help you out here, so a really good parameter name, consistent across your project or organization is a great idea: I like callerMemberName as a direct indicator of the purpose/usage of the parameter.

There are a couple of obvious places to use CallerMemberName – logging and implementing INotifyPropertyChanged.

I asked on Twitter and checked around the Internet, and there are a bunch of simple examples that illustrate CallerMemberName. Here’s one in English, and one in Hungarian. There’s also a version in the documentation for the INotifyProertyChanged interface. If you’re interested in how CallerMemberName works, check these out.

If you’re interested in a bang-up, super-great, sea-salt and malt vinegar (potato chip) version, check out Dan Rigby’s blog posts here and especially here where he evaluates versions of INotifyPropertyChanged that have been used elsewhere. The basics are that the Set method should contain exactly one method call, the event should not be raised unless the property is actually changed to a new value, no strings should be used to avoid typo bugs, and no reflection or callstack access should be used to maintain performance.

I really like the flow of information on the Internet when people find something good and add to it. I have two enhancements I want to add – I hate having SetProperty in every class and I didn’t find a VB version.

First, you can use a common base class to avoid redundant SetProperty methods. This simplifies the data class. Note that it’s common to supply a protected OnPropertyChanged method in a base class. If this is called from something other than the property, such as the SetProperty method, the CallerMemberName can be passed in, passing on or chaining the original property name:

public class Foo : FooBase
{
     private int _bar;
     public int Bar
     {
         get { return _bar; }
         set { SetProperty(ref _bar, value); }
     }
}

public abstract class FooBase : INotifyPropertyChanged
{
     public event PropertyChangedEventHandler PropertyChanged;

     protected bool SetProperty<T>(
             ref T storage, T value,
         [CallerMemberName] String callerMemberName = null)
     {
         if (object.Equals(storage, value)) return false;

         storage = value;
         this.OnPropertyChanged(callerMemberName);
         return true;
     }

     protected void OnPropertyChanged(
             [CallerMemberName] string callerMemberName = null)
     {
         var eventHandler = this.PropertyChanged;
         if (eventHandler != null)
         {
             eventHandler(this,
                  new PropertyChangedEventArgs(callerMemberName));
         }
     }
}

Since I didn’t find this available in VB, I translated:

Public Class Foo
    Inherits FooBase

    Private _bar As Integer
    Public Property Bar As Integer
        Get
            Return _bar
        End Get
        Set(value As Integer)
            SetProperty(_bar, value)
        End Set
    End Property

End Class

Public Class FooBase
    Implements INotifyPropertyChanged

    Public Event PropertyChanged(sender As Object, e As PropertyChangedEventArgs) _
            Implements INotifyPropertyChanged.PropertyChanged

    Protected Function SetProperty(Of T)(ByRef field As T, value As T,
                    <CallerMemberName> Optional callerMemberName As String = Nothing) _
                    As Boolean
        If Object.Equals(field, value) Then Return False

        OnPropertyChanged(callerMemberName)
        field = value
        Return True
    End Function

    Protected Sub OnPropertyChanged(
                    <CallerMemberName> Optional callerMemberName As String = Nothing)
        RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(callerMemberName))
    End Sub

End Class

Colorado Springs Slides

2012-06-15T20:01:00Z

Here are the slides from my Colorado Springs talk - Visual Studio Tips and Tricks.

(Please visit the site to view this media)

TaskCancelledException vs OperationCancelledException

2012-05-25T21:25:40Z

I had a conversation with Stephen Toub, Peter Ritchie and Kevin Hazzard about the different between the TaskCancelledException and the OperationCancelledException. It turns out not to be a big difference, but some understanding might keep you out of a bit of trouble.

TaskCancelledException derives from OperationCancelledException. TaskCancelledException contains a property for the cancelled task.

If you’re catching exceptions, you probably want to catch both exceptions. If you don’t care about the task, you can do this by just catching the OperationCancelledException since the TaskCancelledException derives from it. Or you can catch them both in order if you use the task in your exception response. Catching only the TaskCancelledException will not work in all cases, since it won’t catch OperationCancelledException.

If you’re throwing an exception, and there’s a task available, throw TaskCanceledException. If there isn’t a task available, throw an OperationCancelledException. This is reflected in the framework when the CancellationToken’s ThrowIfCancellationRequested method throws an OperationCancelledException.

If you’re manually throwing cancellation exceptions, check that you aren’t repeating things already handled well by the .NET framework. CancellationTokenSource and CancellationToken may take a little getting used to, but this mechanism provides a predictable approach that handles some tricky threading side cases that will ultimately make your code simpler and easier to understand.

Throwing exceptions to communicate cancellation steps slightly outside usual exception guidelines. Exceptions are intended for exceptional circumstances, and cancellation is arguably not an exceptional occurrence. But, one of the things exceptions do is abort further processing and fail to return a value. Clearly this should happen on cancellation. I think the tradeoff is worthwhile because treating cancellations as exceptions significantly simplifies your code and avoids bogus return values after cancellation.

One of the reasons exceptions are bad for implementing control flow outside exceptional circumstances is that there must be no confusion about the exceptions that are thrown. Let’s avoid confusion J

- Catch OperationCancelledException, and possibly also TaskCancelledException

- Throw TaskCancelledException when you have a task to pass, otherwise OperationCancelledException

Thanks to Stephen, Peter and Kevin - I’m a bit smarter than I was a few hours ago.

Roslyn

2012-04-18T14:43:00Z

I believe project Roslyn is a watershed moment. It will start a complete redefinition of what programming and being a computer programmer means.

But why? How could rewriting the Visual Basic and C# compilers be even a blip in the history of computer programming? At best it’s a sneeze!

Show me a computer program. Right now. Really. At least think through how you would show me.

OK, you just opened up an instance of Visual Studio and showed me Solution Explorer graph of a whole bunch of files. Text.

A small minority of you might have used a different approach –showing me functional tests, a user interface, a database or a dependency graph. An even smaller minority might have shown me a UML diagram, DSL, or other code generation metadata. Six or seven of you might have even opened a decompilation tool or showed me some IL. Two or three of you might have discussed semantics. One of you, just maybe, opened a workflow designer (ah, the sad story of Workflow is for another day).

The line between these realities has been stark. You’re writing code or your ditzing around with the tools that support you writing code. Text. Text. Text.

A computer program has always been all of these things and something else. Something ethereal that existed between your ears and my ears. As programs have become more complex, we become increasingly desperate to live in the ecosystem of our application instead of in the code. That’s what agile was all about. Agile makes our application into an ecosystem of players. So does DSL. But in both cases we’re blind and playing with only parts of the elephant.

Wait, code matters. Of course code matters! It is one expression of abstraction along the pipeline from idea to electrons moving in silicon. Code is the last thing that normal humans will comprehend. It becomes IL that a platform specific compiler understands, and then some magic happens. That end works. With apologies for the analogy, we know how to take the elephants output and fertilize the garden. The apps work. We just feed the elephants badly because we do not understand them.

Oh, just forget that analogy, it was gross anyway.

What we need to understand is that no one today understands what an application is. We can’t. We can’t because the way we reason about anything is predetermined by the wiring of how we sense it. To understand what applications are in new ways, we need new ways to sense them, redefine what they are and place them in rich ecosystems with no rigid boundaries of definition between problem and solution. It’s easiest to visualize as no rigid boundaries between text and graphics, but that will feel like a very shallow distinction within five years.

While no one understands what an application is today, no one can stop us coming to a new understanding and a new relationship in the next five years. Roslyn is not birthing in a vacuum. We have relatively mature ecosystems in DSL and functional languages. We have an emerging (about to be exploding) work happening in composition and semantics. We have ongoing research in algorithms. We have a lot of work in the areas of agile, quality, reasoning/diagraming, requirements, human interfaces, etc. We are ready.

Roslyn, for us in the .NET world, is the snowball tossed to start the avalanche of change. It will do this because it will lead us to think of our code as a semantic tree. Such a tiny, tiny thing. And then we’ll have the most amazing array of IDE tools, and then new DSL/generation tools, and then amazing new composition reasoning, and then…, and then… , and then… , and then… , and then… Each will lead us to new thinking about the next and around the tenth or hundredth “and then” it will be obvious how seismic the shift.