Windows Service in .NET using ServiceRunner

About six months ago I wrote a tiny bit of code that I called ServiceRunner. I put it up on NuGet and GitHub. but never got around to blogging about it until today. And since I’ve already blogged today about writing a Windows Service, it seemed a good time to share.

Why? Because I had grown tired of wiring up a Windows Service host for one project or another and wanted to reduce it down to the very least amount of code possible all while keeping the project as a standard console app to make debugging as simple and easy as possible.

Here is the easiest path to a working Windows Service:

  1. Create a .NET console app in Visual Studio.
  2. Install the NuGet package called ServiceRunner with Install-Package ServiceRunner.
  3. Add a class that inherits from ServiceRunner.ServiceRunnerInstaller as shown below.
  4. Add a simple bit of code to your console app’s Main method as shown below.
  5. Build and debug with the Runner’s runAsConsole constructor parameter set to false.
  6. When ready to deploy as a service, change that parameter to true. How you do that is up to you.
  7. Now run the InstallUtil command line installer as installutil c:\yourpath\yourapp.exe -i and your service is installed and ready to run. (If you use a Visual Studio command line, installutil will be in your path. Otherwise you’ll find it in the .NET framework install directory under C:\Windows\Microsoft.NET\Framework{64}\{version}.)

Here’s the code for the required installer class:

using ServiceRunner;

namespace ServiceRunnerDemo
{
   /// <summary>
   /// This class (name unimportant) must exist in your console app
   /// for the installer to be recognized when you run installutil.exe
   /// from the Windows\Microsoft.NET\Framework64\v4.0.30319 directory.
   /// </summary>
   public class MyInstaller : ServiceRunnerInstaller
   {
      protected override string ServiceName
      {
         get { return "ServiceRunner"; }
      }

      protected override string ServiceDescription
      {
         get { return "Service Runner description"; }
      }

      protected override string ServiceDisplayName
      {
         get { return "Service Runner"; }
      }

      protected override ServiceRunnerStartMode StartMode
      {
         get { return ServiceRunnerStartMode.Manual; }
      }

      protected override ServiceRunnerAccount Account
      {
         get { return ServiceRunnerAccount.LocalSystem; }
      }
   }
}

And here’s the code for the console app Main method.

using System;
using System.IO;
using ServiceRunner;

namespace ServiceRunnerDemo
{
   class Program
   {
      static void Main(string[] args)
      {
         var logFile = "c:\\temp\\logit.txt";
         var runner = new Runner("MyServiceRunnerDemo", runAsConsole: false);
         runner.Run(args, 
            arguments =>
            {
               // equivalent of OnStart
               File.WriteAllLines(logFile, new string[]
               {
                  string.Format("args count: {0}", arguments.Length)
               });
               Console.WriteLine("args count: {0}", arguments.Length);

               // normally you would launch a worker thread here 
               // to do whatever your service would do 

               File.WriteAllLines(logFile, new string[]
               {
                  "start called"
               });
               Console.WriteLine("start called");
            }, 
            () =>
            {
               // equivalent of OnStop
               File.WriteAllLines(logFile, new string[]
               {
                  "stop called"
               });
               Console.WriteLine("stop called");
            });
         Console.ReadLine();
      }
   }
}

As you can see, the code is very simple. Far less to worry about than using the standard Visual Studio project template or trying to manually cobble up the installer and other pieces required. If you get any good use out of it, I would love to hear from you.

Happy Windows Service writing!

Windows Service in the D Programming Language

Nine months ago I blogged about my curiosity about the D programming language. It is possible that this curiosity is turning into a hobby. Time will tell. Recently I decided to create a Windows Service written in the D programming language. I’ll share my journey to that end here.

When I started I assumed it would be easy to find examples in the open source world from which I could learn. That assumption turned out to be mostly false. I found some posts on the forum that were helpful. I then dug up an email address using that famously free detective, Google. Graham Fawcett was very helpful in sharing some code with me but for some reason I could not get it to work.

After a week or more of evenings attempting to find a solution, I gave up and offered a bounty on the forum. And Vladimir Panteleev, a regular D community contributor, came to my rescue and gladly took the $100 bounty to be applied toward other issues he would like to see resolved. My deep thanks to both of these community members.

As it turns out, the code that Graham shared with me would have worked except the Win32 bindings code had an x64 bug that would not have manifested itself had I been compiling for x86. Specifically, the winsvc.d code file contained the line:

alias DWORD SERVICE_STATUS_HANDLE;

I took Vladimir’s advice and changed it to:

alias size_t SERVICE_STATUS_HANDLE;

And then later pulled in his final fix as;

mixin DECLARE_HANDLE!("SERVICE_STATUS_HANDLE");

I won’t try to explain the differences here. In any case, the handle in x64 world needed to be a ulong and it was getting declared as a uint (C# equivalents here). And once that was resolved, I was very happy to see the code work.

You can get or read the code for that first success on GitHub. I refactored that code using a reference app in C++ that followed a familiar pattern having written many Windows Service in C#, even to the point of writing a short cut to standing up a Windows Service in .NET.

In any case, if you are curious to see my first real foray into the world of D programming, you can check out the code on GitHub. It even includes a minor improvement suggested by a forum member already. And if you have questions or need help, please leave a comment and I will do my best to help.

TechEd: ASP.NET and C# Bonanza

Sadly I was unable to attend, but watching a few videos over the weekend is enough to get my juices flowing for what is coming down the pike for .NET and ASP.NET and C#. Here are a few notes and links:

Amazingly cool stuff coming up for .NET:

Next Generation of .NET for Building Applications

  • .NET Native: (22:40) will eventually be available beyond Win 8 RT apps
  • SIMD: (36:00) up to 8x performance improvement in parallel operations on multiple data streams

Future of Visual Basic and C#

  • Roslyn
    • super fast in-memory next generation .NET compiler
    • inline renaming - wow!
    • open source - on codeplex
  • C#
    • primary ctor: public class Point(int h, int w)
    • getter only auto property: public int Height { get; } = h;

Even more amazingly cool stuff coming for ASP.NET:

The Future of .NET on the Server (intro)

The Future of .NET on the Server (deep dive)

ASP.NET vNext

Oh so much to learn and play with. It’s a good time to be alive!

Unmanaged Memory in C# and the Power of Marshal.AllocHGlobal

There are a variety of reasons one might wish to use unmanaged memory in C#, taking advantage of the Marshal class and it’s powerful AllocHGlobal method. The reasons are less important here than the how, at least the how I have learned to do so.

First, you need to know about the word blit and Microsoft’s usage of that word: blittable types. I’ll wait while you catch up.

Next, you need to understand how to construct a complex value type that Microsoft likes to call a “formatted value type.” [sic] To create a formatted value type, you will need to use the StructLayout attribute and the FieldOffset attribute. While not strictly required, these attributes will keep you from wasting precious memory. Here’s an example:

[StructLayout(LayoutKind.Explicit, Size = 8)]
internal struct MyData
{
   [FieldOffset(0)]
   public short Level;

   [FieldOffset(2)]
   public int Weight;

   [FieldOffset(6)]
   public short Indicator;
}

Before you dive into use the AllocHGlobal method to grab some of that raw unmanaged memory that you want, be sure you have first prepared your code to let it go using the FreeHGlobal method. My preference is to do it by implementing IDisposable and a class destructor just in case I forget to dispose of my object that holds my precious unmanaged memory in its hands. Like this:

private bool disposed = false;

~MyPage()
{
   Dispose(false);
}

public void Dispose()
{
   Dispose(true);
   GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
   if (!this.disposed)
   {
      this.disposed = true;
      if (this.myPtr != IntPtr.Zero)
      {
         Marshal.FreeHGlobal(this.myPtr);
         this.myPtr = IntPtr.Zero;
      }
   }
}

Now you are ready to grab some memory and use it unsafely but responsibly with all the benefits that come from doing so. Here’s an example. Of course there are many more things you can do with unmanaged memory, but this will get you started.

public class MyPage : IDisposable
{
   private IntPtr myPtr = IntPtr.Zero;
   
   public MyPage(long capacity)
   {
      long size = Marshal.SizeOf(typeof(MyData));
      long totalBytes = capacity * size;
      this.myPtr = Marshal.AllocHGlobal(new IntPtr(totalBytes));
   }
   
   public MyData this[long index]
   {
      get
      {
         unsafe
         {
            return ((MyData*)this.myPtr.ToPointer())[index];
         }
      }
      set
      {
         unsafe
         {
            ((MyData*)this.myPtr.ToPointer())[index] = value;
         }
      }
   }
   
   
   private bool disposed = false;
   
   ~MyPage()
   {
      Dispose(false);
   }
   
   public void Dispose()
   {
      Dispose(true);
      GC.SuppressFinalize(this);
   }
   
   protected virtual void Dispose(bool disposing)
   {
      if (!this.disposed)
      {
         this.disposed = true;
         if (this.myPtr != IntPtr.Zero)
         {
            Marshal.FreeHGlobal(this.myPtr);
            this.myPtr = IntPtr.Zero;
         }
      }
   }
}

You will note that I have not included bounds checking in the above code, nor have I shown any code for initializing the data. Yes, this is living dangerously, but it is also one of the main reasons for using unsafe access to unmanaged memory—the performance advantage of not checking bounds. So drive safely. And if you are using unmanaged memory from C# for something clever or amazing, please tell us about it in comments.

Aspect Oriented Programming Not Worth It

I have said before that I like Uncle Bob's way with words. This includes his Clean Code Discussion:

"When aspects first came out, I was intrigued by the idea. But the more I learned, the less I liked it. The problem is that the pointcuts are tightly coupled to the naming and structure of the code. Simple name changes can break the pointcuts.  This, of course, leads to rigidity and fragility. So, nowadays, I don't pay a lot of attention to AOP. 

"For my money, the OO techniques that I demonstrated for logging can be pretty easily used for many other cross-cutting concerns. So the tight name-coupling of AOP isn't really necessary."

I too once thought that AOP was a great idea. A carefully crafted AOP solution can even overcome some of the coupling issues that Uncle Bob mentions. But eventually the dependency entanglements even with nice clean injection techniques, pick your poison, you end up with a hodge-podge of rigid and fragile. Eventually you find yourself writing code to serve your AOP solution rather than your use case.

My money is with Bob.

.NET Goes Native

I am very excited about the .NET Native project. And while this is just for WinRT app store apps right now, I was encouraged by the commentary in the Channel 9 presentation. I am eager to learn more about it.

For a long time, the speed of desktop processors has spoiled us, allowing us to depend on heavier and heavier JIT workloads and dynamic utilization of multiple core libraries. With the challenges of mobile coming along, we get the benefit of heavy duty platform specific optimization in .NET Native now.

Because I often write server applications in C# that could really benefit from that extra platform optimization, I am hoping and looking forward to being able to utilize .NET Native in my work as well.

Uncle Bob on TDD

I rarely parrot blogs here but sometimes I find a post I don’t want to lose track of. Robert Martin (Uncle Bob), one of my favorites, just posted The Domain Discontinuity which asks the question: Which came first, the chicken or the road?

Two quick pull quotes.

The first has to do with the appropriate scope of TDD. Why do I include this? Because I am not a TDD fanatic. By fanatic, I mean those developers who would disagree with Uncle Bob here, even going so far as to make private and protected methods public just so their tests can access them.

“Let me stress this more. I do not create a test for every method or every class. I create tests that define behaviors, and then I create the methods and classes that implement those behaviors.

“At the start, when there are just a few tests, I might have only one simple method. But as more and more tests are added, that one simple method grows into something too large. So I extract functions and classes from it -- without changing the tests. I generally wind up with a few public methods that are called by my tests, and a large number of private methods and private classes that those public methods call; and that the tests are utterly ignorant of.

“By the way, this is an essential part of good test design. We don't want the tests coupled to the code; and so we restrict the tests to operate through a small set of public methods.”

The second pull quote is a small set of architectural principles that I completely agree with:

    • Refactoring across architectural boundaries is costly.
    • Behaviors extracted across architectural boundaries need newly rewritten tests.
    • Architecture is an up-front activity.

“The solution to that problem is to know in advance where you are going to put certain behaviors. You need to know, in advance, that there will be a boundary between the GUI, the business rules, and the database. You have to know, in advance, that the features of your system have to be broken up into those areas. In short, before you write your first test, you have to ‘dream up the [boundaries] that you wish you had’.”

I sometimes come across systems that are woefully inadequate to the task, extremely difficult to refactor, and have few, if any, tests that do not require integration across boundaries that are often, if not almost impossible, to mock or fake. Virtually all of these problems are attributable to the false notion that Agile means you rush to coding and skip up-front architectural analysis and design.

Thanks, Uncle Bob!

ServiceWire 1.5.0 Released

ServiceWire is a very fast and light weight service host and dynamic client library that simplifies the development and use of high performance remote procedure call (RPC) communication between .NET processes over Named Pipes or TCP/IP.

The DuoVia.Net library has progressed significantly. But everyone I work with who uses it balks at the name. So I’ve renamed it. And I like the name very much. I hope you do too. It is ServiceWire. This name more aptly describes intuitively what the library does. Hopefully this will help with adoption and participation.

I’ve laid out the documentation wiki on that site and will spend the next few days or weeks getting it completely fleshed out. The code is in a new repository and there is a new NuGet package which, with the exception of namespaces, is at perfect parity with DuoVia.Net version 1.5.0.

I’m very interested in getting your feedback on ServiceWire, the name and the library.