Your source of geek knowledge

TransactionScope and Async/Await. Be one with the flow!

I’m doing a series of async/await related blog post on the particular blog. This one might also be interesting for you.

You might not know this, but the 4.5.0 version of the .NET Framework contains a serious bug regarding System.Transactions.TransactionScope and how it behaves with  async/await. Because of this bug, a TransactionScope can’t flow through into your asynchronous continuations. This potentially changes the threading context of the transaction, causing exceptions to be thrown when the transaction scope is disposed.

This is a big problem, as it makes writing asynchronous code involving transactions extremely error-prone.

The good news is that as part of the .NET Framework 4.5.1, Microsoft released the fix for that “asynchronous continuation” bug. The thing is that developers like us now need to explicitly opt-in to get this new behavior. Let’s take a look at how to do just that.

TL;DR

  • If you are using TransactionScope and async/await together, you should really upgrade to .NET 4.5.1 right away.
  • A TransactionScope wrapping asynchronous code needs to specifyTransactionScopeAsyncFlowOption.Enabled in its constructor.

If you want to learn more about async/await and how to flow TransactionScopes over continuations, I suggest you read the full blog post originally posted on the particular blog.

Async/Await: It’s time

I wanted to briefly mention a blog post which I wrote on the particular blog. It is a product centric announcement around the Particular Platform about the move towards an async-only API. Although it is product centric I believe this post contains a lot of valuable information around async/await and its benefits and caveats. In my biased opinion, it is definitely worth a read.

Async/Await is a language feature introduced in C# 5.0 together with Visual Studio 2012 and the .NET 4.5 runtime. With Visual Studio 2015 almost ready to be shipped to end-users, we can see that async/await has been around for quite some time now. Yet NServiceBus hasn’t been exposing asynchronous APIs to its users. Why the await?

We have been carefully observing the adoption of async/await in the market and weighing its benefits against its perceived complexity. Over the years async/await has matured and proven its worth. Now the time has come to discuss our plans regarding the async/await adoption in NServiceBus and our platform.

TL;DR

  • Future versions of the NServiceBus API will be async only.
  • Synchronous versions of the API will be removed in future versions.
  • Microsoft and the community have made this decision for you, by moving toward making all APIs which involve IO operations async-only.
  • Don’t panic! We will help you through this difficult time.

You’re going to be blown away by the additional benefits that asynchronous NServiceBus APIs will provide. But first, let’s review why asynchronous APIs are such a big deal in the first place.

If you want to learn more about async/await, I suggest you read the full blog post originally posted on the particular blog.

Stuff I learned yesterday

I listen to a few podcasts. Mainly technical ones. I recently got a hint from Mike Minutillo about a podcast called “Stuff I learned yesterday”. I was blown away when I started listening to this podcast. It makes you think more about stuff that you learned. Furthermore, this podcast is full of stories from the podcasters themselves but also from the community. You’ll find the podcast here

http://www.goldenspiralmedia.com/stuff-i-learned-yesterday

One of the recent inspiring and very emotional episodes are

Finding clarity
http://www.goldenspiralmedia.com/stuff-i-learned-yesterday-episode-302-finding-clarity

If you have lost someone in your life like I did, you know why I like this one.

Are they even listening?
http://www.goldenspiralmedia.com/stuff-i-learned-yesterday-episode-296-are-they-even-listening

If you are a parent, like I am, you know why I like this one.

Subscribe! It is emotional, inspiring, makes you laugh, cry, think…

Post picture by http://www.gotcredit.com/

Mining for gold in your logfiles

Once you’ve already learned the ins and outs of a library, it may seem obvious how it should be used (and which parts should be avoided). The thing is that, from one project to the next, we often make use of new and different libraries and frameworks and may not appreciate some of the more subtle differences among those technologies.

The better frameworks out there will log all kinds of information, often telling you when you’re using them incorrectly. So don’t just think of log files as something only relevant for production. There are nuggets in there that can really help you in development as well.

Look at your log files at regular intervals. Doing that from time to time and, even better, automating it, can save you from headaches even before you release your products into production. Eventually, this practice will not only prevent bugs but it can also dramatically improve performance in certain cases.

If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.

Machine.Specifications – The alternative nunit

In my last post, I explored xunit as an alternative to MSpec. In this blog post, I’m going to do the same with NUnit. Most people underestimate the power of NUnit. It is a great testing framework that has been around since the early days of .NET and Open Source and is still actively maintained. When it comes to tool integration, NUnit has one major advantage: The Resharper plugin is developed by JetBrains and shipped together with every Resharper release. So everybody which uses NUnit never has to worry about if there will be a Resharper integration. Furthermore, they’ll never worry about the plugin no longer being maintained (like in other One-Man-Show-Plugins). In fact there is even a 3.0 Beta release currently available of NUnit, all development is done on Github. Be sure to check out the release notes! Yes, yes nitpickers, it uses attributes and such but who cares?

So to reimplement the basic functionality of Machine.Specifications you need Continue reading

Machine.Specifications – The alternative xunit

In my last post, I showed how a Heisenbug can look like to you. In this post, I want to explore the different options I was considering to get rid of some of the pesky things around Machine.Specifications. During the work, I did for Machine.Specifications I asked myself more and more if it is really worth maintaining a whole ecosystem of tools when there are excellent frameworks available in the Open Source world. Why did I even look at alternatives? Why didn’t I just say, that’s it and move away from Machine.Specifications? Continue reading

OMG! They Killed My Stacktrace!

I can’t get that flashing red light on my desktop out of my mind. It’s nagging me. What is it? Oh my… I just killed the build! How embarrassing — only a few weeks on the team and I’m already a trouble-maker. Resistance is futile. The flashing red light got me. Five acceptance tests are failing on the build server. Hold on — those tests are working on my machine! Can’t I just add a works on my machine badge and carry on with the other things I have in the work pipeline? The “getting things done guy” inside me says yes, but my engineer heart tells me no. I roll up my sleeves and start analyzing what went wrong.

If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.

Machine.Specifications – The Heisenbug

In my last post, I talked about me moving away from maintaining Machine.Specifications. Today I want to give you more insights into the decision process and what else I tried to save the project. When I was working for bbv Software Services AG, I was heavily using MSpec in multiple projects. I and also others in the company liked the lightweight syntax and the code-centric approach to specifications by example. We used it so much that it became together with SpecFlow one of our strategic open source library for specifications. We used SpecFlow in projects where the product owner or business analysts took the time to learn and write Gherkin. We used MSpec when the development team was writing the specifications (of course as closely as possible with the business). Continue reading