Here is the code from my talk at Tulsa TechFest on SignalR. Thanks to those of you who came to the talk, I hope you learned enough about SignalR to determine if it’s the right technology for you. Be sure you have enabled NuGet to restore packages on build so the required references all get downloaded and installed from the NuGet site.
Last weekend, the guys from .NET Rocks! interviewed me for the show, and the show is now available from the usual outlets (iTunes, etc.). You can read the summary on their web site, as well as listen to the show! It was a fun discussion that covered a variety of topics, including MassTransit, Topshelf, Magnum, and other open source themes.
When we created Topshelf, one of the prime directives was ease of use. It had to be easy for the developer to add a reference and create a service. To keep it easy, we had another prime directive: the developer should only be required to reference a single assembly to get Topshelf to work. And that assembly should have no dependencies.
Before NuGet, using open source was difficult for .NET developers. With so many different versions of assemblies and no single point of distribution, it was a continuous effort to get a solution with multiple open source dependencies to build properly. Fast forward to today, the NuGet world, and developers can simply add a reference using the NuGet package manager and all the dependencies come along for the ride. The migration of the community towards NuGet has made the directive of one assembly significantly less important.
This evolution of the open source community requires authors to re-imagine their products to fit properly in this new world. In order to keep Topshelf the best and easiest way to create Windows services, we are planning to do just that — re-imagine the model for Topshelf going forward.
With the release of Topshelf 3.0, the main NuGet package will contain only the functionality necessary to create, install, and control your own service. By focusing on this single goal, the highest level of safety and stability can be attained. This allows allows us to keep the footprint of Topshelf as small as possible, reducing the surface area around your mission-critical services that are running on it.
Once we have the main Topshelf assembly stable and production tested, we will revisit the other features of Topshelf and look at how it they fit into the new direction. Some features may be discarded while others may be changed to be more operationally sustainable. These features, however, will not be included in the main package. Instead, they will sit on top of the stable and proved Topshelf assembly, ensuring that the core functionality remains solid.
I’ll be posting a prerelease version of 3.0 on the main NuGet feed in the next few days. This version will continue to support both .NET 3.5 and .NET 4.0, as well as .NET 4.5 once it is generally available (the 4.x version should work with 4.5 until then). The previous v2.x code branches will be renamed from (develop/master) for retention (v2_develop/v2_master).
Migration from previous versions should be fairly painless as the API is nearly identical. There are a few minor tweaks and some additional options for using the new features (such as the ability to control the host from the service, including the ability to stop the service — a very requested feature), most of the settings such as service name and such are now entirely optional, with the default using the namespace of the hosting assembly for the service name.
That’s the current roadmap for Topshelf. Hopefully you’ll agree that this reboot makes sense, as the current codebase has completely outgrown what is needed to host a simple service. Using this additive approach should make it easier to build features on top of the solid core Topshelf service, without comprising the integrity of the base service host functionality.
Last night, I announced that the first release of my benchmarking library Benchmarque was available on NuGet. This morning, I’d like to share with you what the library is, and how it to use it.
Benchmarque (pronounced bench-mar-key) allows you to create comparative benchmarks using .NET. An example of a comparative benchmark would be evaluating two or more approaches to performing an operation, such as whether for(), foreach(), or LINQ is faster at enumerating an array of items. While this example often falls into the over-optimization category, there are many related algorithms that may warrant comparison when cycles matter.
To understand how to use Benchmarque, let’s work through an example. First, start Visual Studio 2010 Service Pack 1 with NuGet 2.0 installed and create a new class library project using the .NET 4.0 runtime. Once created, we’re going to define an interface for our benchmark.
In this benchmark, we are going to compare the performance of the different ways to append text into a single string. Now that we have the interface defining the behavior we want to benchmark, we need to create a few implementations that perform the operation.
First, the good old concatenation operator.
Next, we’ll use a StringBuilder to handle the work.
And last, we’ll try to use string.Join with an empty separator.
With our three implementations ready to benchmark, we now need to create an actual benchmark. We’ll take a list of names, and call the interface with those names. Before we can do that, however, it’s time to add Benchmarque to the project. Using the NuGet package manager, install Benchmarque to your class library project.
Once installed, we can create our benchmark class as shown below.
A benchmark includes three methods that involve the execution of the benchmark, along with a property that returns the iteration counts for each run. WarmUp is called with the implementation to allow any one-time initialization of the implementation to be established. This allow should include a few runs through the test to allow the runtime to JIT any code to ensure the benchmark only includes actual execution time (versus assembly load and JIT time). The Run method is then called with each of the iteration counts to actually run the benchmark. Once complete, the Shutdown method is called to dispose of any resources used by the implementation.
The benchmark runner (Benchmarque.Console, which is installed in the tools folder by NuGet) will run the benchmark with each implementation and measure the time taken. To run the benchmark, we need to open the NuGet Package Manager Console, change to the assembly folder, and start the benchmark using Start-Benchmark as shown below.
Once open, change to the folder for the assembly to benchmark.
And now, we’re going to run the actual benchmark and view the results.
First, Start-Benchmark is a Powershell function that is added by the init.ps1 that’s included in the NuGet package. It handles the execution of the benchmark using the console runner. Once complete, the output of the benchmark is displayed in the console window.
As shown above, the results of the test execution are ordered with the fastest implementation first, followed by the remaining implementations with the difference and how many times slower it is displayed. The output is pretty basic at this point, without a lot of other calculations displayed. Additional items may be added as some point. For now, it’s enough to give me the answers I need when trying different approaches to the same problem.
The library is open source (I’ll put the Apache 2 documents in place at some point), so feel free to use, abuse, modify, and enhance as needed!
One request: If anyone is a Powershell megastar and can modify the Benchmarque.psm1 so that if no argument is specified, it looks through the solution for the projects that are referencing Benchmarque, and automatically running the benchmarks in those assemblies so they don’t have to be specified explicitly.
I’m happy to announce that I have been awarded the 2012 Microsoft® MVP award for my technical contributions to the Visual C# community over the past year. This is the fourth consecutive year that I have received the award, and I greatly appreciate the recognition. I would also like to thank everyone who has supported me over the past year, allowing me the time to prepare interesting content, travel to amazing conferences (including my first trip to Sweden last year), and deliver engaging presentations to the software development community.
As I look back at the past three years, the most rewarding benefit of being an MVP awardee is communication with the product teams at Microsoft. Being able to discuss product goals, features, and roadmaps with the actual development teams is extremely valuable. When I look at how Microsoft has evolved over the past couple of years alone, I see a company that is embracing open source (look at the full ASP.NET web stack) and retooling their development products to facility greater sharing of open source libraries (NuGet, for example). I look forward to even more interaction with the teams over the next year as the Windows platform adapts to the changing modalities in personal computing.
Last week, I gave a talk at the Northwest Arkansas .NET user group on SignalR. Based on the response (as I’ve seen at nearly every event I’ve spoken about SignalR), there is a lot of interest in this library for building rich HTML applications with .NET backend services.
The demo code from the talk, which includes an action item list, along with an external service that posts events to browser clients via MassTransit, is available for download below.
Last week, I had the pleasure of attending Øredev in Malmö, Sweden. While at the conference, I presented two sessions — including a new talk on Actor Model Programming in C#. This was the first official presentation I’ve given on the subject, having done an ad-hoc version of the session at Pablo’s Fiesta this year (which went fairly well, likely due to the awesome Chicken and Waffles at 24 Diner the night before). Early feedback from the Øredev session was positive, which is encouraging since I will be giving an updated version of the talk at CodeMash 2.0.1.2 in January.
First, I wanted to share a few links to the content discussed in the session, including the GitHub Project, the NuGet package, and the TeamCity build. I will update the post with the video link once the presentation video is available, along with the slide deck.
Second, I plan to post a series of blog posts explaining how actor model programming is a great model for building concurrent applications, despite the difficulties that the actor model has had in becoming more mainstream (some of those difficulties are explaining in this article by Paul Mackay).
In the meantime, I’m going to take a hard look at how different languages have implemented the actor model (many of which have influenced the current syntax used in Stact). I’m also taking a step back and identifying other ways the model can be implemented the minimize many of the difficulties and bring some modern programming style to the model. Concurrency is certainly difficult, but I’m convinced that many aspects can be made more approachable by applying some existing idioms to the problem.
If you do take a look at Stact, please offer any feedback you have via Twitter (I’m @PhatBoyG) or GitHub (using issues, whatever). If the traffic grows, we’ll setup a Google group to keep things manageable.
Until next time…
After what seems like a long slumber, along with work being done on other projects such as Topshelf and Stact, it is our great pleasure to announce the first beta release of MassTransit v2.0. What originally started out as a minor “1.3” update has turned into a full-out cleanup of the codebase, including a refinement of the configuration API. Since there were some breaking changes to the configuration, we felt a 2.0 moniker was better to ensure users of the framework understood the depth of the changes made.
And what a list of changes it is (TL;DR = We filled it with awesomeness):
Configuration
MassTransit v2.0 now includes a streamlined configuration model built around an extensible fluent interface (inspired by Stact and Topshelf and sharing a common, consistent design). As a result, getting started with MassTransit is now easier than ever. In version 2.0, all configuration starts with the ServiceBusFactory and Intellisense guides you from there forward. The result is a clean, understandable API and a quicker out-of-the-box experience.
Container-Free Support
With the release of MassTransit 2.0, using a dependency injection container is now optional. When we started MassTransit, we leveraged the container extensively to assemble the internal workings of the bus. As we added support for other containers, required features that were not supported by a particular container led to some creative solutions (read: hacks) that were less than optimal. By moving away from a “container-first” approach, we have increased the reliability of the software and now provide container-specific extensions to subscribe consumers from the container in one simple step. We also threw in support for Autofac!
Quick-Start
By simplifying the configuration, and dropping the need for a container, it is now fast and easy to get started using our new QuickStart:
http://docs.masstransit-project.com/en/latest/configuration/quickstart.html
#NuGet
NuGet packages have been added for the base MassTransit project, with any external dependencies (log4net and Magnum) resolved using the proper NuGet packages. Any additional references are downstream in additional NuGet packages, such as support for persisting sagas using NHibernate (MassTransit.NHibernate), and the various dependency injection containers supported.
Multiple Subscription Service Options
In addition to the existing RuntimeServices included with MassTransit, an all-new peer-to-peer subscription service has been added. By leveraging the reliable multi-cast support in MSMQ, services can now exchange subscription information without the need for a centralized subscription service. To ensure everything is setup correctly, a VerifyMsmqConfiguration method has been added that will check the installation of MSMQ and install any missing components. This is the first iteration of multi-cast support, and we need to get some mileage on it. In the meantime, the original run-time services continue to work as expected.
Documentation
Which brings us to the next big update. DOCS! They’re not perfect, and they’re far from complete, but we have focused on the configuration story to help get you up and running. As we see a need for more documentation in a given area, we will continue to flush out the docs appropriately. The docs are located at http://docs.masstransit-project.com/ and are being hosted by the fine people at http://readthedocs.org. [Thanks Eric!]
Support for .NET 4.0 and .NET 3.5
The project files and solution have all been updated to Visual Studio 2010 SP1. By default, all projects are now built in the IDE targeting .NET 4.0. The command-line build (which has been revamped to use Rake and Albacore) builds both .NET 3.5 and .NET 4.0 assemblies, including the run-time services and System View. The NuGet packages also include the proper bindings for the target project run-time version (you must use the full .NET 4.0 profile with MassTransit, the client profile is not supported).
Transport Support
Internally, the transports and endpoints have been redesigned to improve the support for new transports like RabbitMQ (and improve our ActiveMQ support). For example, transports are now inbound, outbound, or both, allowing us to properly leverage fan-out exchanges on RabbitMQ for publishing and subscribing to messages. There is more to come in this area as we take greater advantage of these advanced transport features. If you’re a RabbitMQ or ActiveMQ user and don’t mind getting your hands dirty, now is a great time to jump in and help improve transport support.
Distributor Consumer And Saga Support
Work on the MassTransit distributor subsystem continues to be improved. Testing on a multi-master system has been completed which will allow it to serve multiple distributors to improve load balancing efficiency. Support for all sagas (previously only state machine sagas were supported) has been added as well.
Swinging the Feature Axe
Some previous troublesome and poorly supported features (Batching and Message Grouping) were removed from the 2.0 release to reduce code complexity. Also in light of the new Parallel Tasks work in the framework the Parallel namespace has been removed.
In the next few days, I’ll be posting an annotated walkthrough of the new configuration API. In the meantime, fire up Visual Studio 2010, create ConsoleApplication69, switch to the full .NET 4.0 framework, and Add a Library Package Reference to MassTransit using NuGet. Paste the code from the Quick Start into your program.cs and check it out!
