I was playing around with an Azure solution consisting of a Web Role serving up some REST endpoints and a Worker Role for background processing. Seemingly without reason, I would all of a sudden get a HTTP error 403 when the browser starts up and tries to navigate to the site. I also got a 404 when I ignored the 403 and tried to invoke one of the exposed endpoints by my Web Role. Several searches online didn't seem to produce anything usable.

After trying out various things for a couple of hours, I decided to go about this in a more methodical manner. Ignoring for now the 404, thinking it could be a consequence of the 403, I decided to try to understand how the 403 came about. Looking at the site in question, I did see that the web.config had an entry allowing directory browsing. So, here was the first hint: If directory browsing is allowed, why was I getting an Access Denied when debugging the solution? Also, could the root cause of the 403 also be the root cause of the 404 returned when trying to invoke the endpoint?

It turns out the answer is yes. What I had inadvertently done was to move the web.config into a different folder in my Visual Studio solution. I didn't even consider that this would also physically move the file on the file system. Obviously, if the file is moved into a different folder (which I did actually notice, but I was too deep in the mud at that point, so I discarded that) IIS will not find it when mapping the request to the file system, and the site will not be configured correctly. So, when I moved the web.config file back to the original location in Visual Studio, things started working flawlessly again.

Morale: Think about what error message is plainly visible. If you are getting an Access Denied (403), there is a good chance that your site has been misconfigured for some simple reason. I hope this post helps others who find themselves in a similar situation.

Knowing that we will call the PSIs ourselves, this leads to the first decision that has to be made: How will we call the back-end from the extension service? There are a couple of options. One option is to generate proxy objects that match the services exposed by the PSIs. Another option is to use the interface assemblies directly and do more of the plumbing yourself. It seems to me that the former method is well described; I will use the latter approach. Personally, I prefer this method for a couple of reasons: I always find the code that is generated off the MEX data is clunky and ugly. And, too much of it is generated – you typically end up with more files than strictly needed when you go this route. Further, it gives me a sense of being more in control when using the interfaces explicitly and creating the channels myself etc.

The next thing that has to be decided is the signature of the operation. The interesting thing to decide is how to handle return types and parameters. Project Server relies heavily on datasets to pass data between client and server. Therefore, it would be a natural approach to use the typed datasets and rely on the assemblies that are installed with Project Server. Another approach is to serialize everything to XML yourself and so be totally platform independent. This is the approach that I have chosen: My extension service is relatively simple, and I don’t want the hassle of assemblies that have to be deployed. So, with that in mind, I can rely on simple types such as a string containing all the data of the retrieved dataset as XML.

With the decisions behind us, we can start to write the code. First, we have to change the contract of the extension service. Instead of having a method called EchoHello, let’s call it something more appropriate: ReadTimesheetListForCurrentUser makes the entire contract definition look like this:

namespace Project.Server.Extensions

{

   [ServiceContract]

   internal interface IExtensionPSIService

   {

      [OperationContract]

      string ReadTimesheetListForCurrentUser();

   }

}

Also change the actual implementation so that it looks like this:

// Other using declarations omitted for brevity

using Microsoft.Office.Project.Server.Interfaces;

using Microsoft.Office.Project.Server.Schema;

namespace Project.Server.Extensions

{

   [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

   internal class ExtensionPSIService : IExtensionPSIService

   {

      private static string serverUri;

      private static BasicHttpBinding binding;

      #region IExtensionPSIService Members

      [OperationBehavior(Impersonation = ImpersonationOption.Required)]

      public string ReadTimesheetListForCurrentUser()

      {

         try

         {

            // Get the user ID of the calling user

            var resourceChannel = CreateClientChannel<IResource>();

            Guid userUid = resourceChannel.GetCurrentUserUid();

            ((IClientChannel)resourceChannel).Close();

            ((IClientChannel)resourceChannel).Dispose();

            // Get the time sheet for the user

            var timeSheetChannel = CreateClientChannel<ITimeSheet>();

            var timeSheetData = timeSheetChannel.ReadTimesheetList(userUid,

               DateTime.Now.AddDays(-7),

               DateTime.Now,

               1);

            ((IClientChannel)timeSheetChannel).Close();

            ((IClientChannel)timeSheetChannel).Dispose();

            // Get a reader of the data...

            var xmlData = timeSheetData.GetXml();

            return xmlData;

         }

         catch (Exception)

         {

            throw;

         }

      }

      #endregion

                …

Let’s go through the code in greater detail:

I start by declaring a couple of variables that I will need during operation: serverUri is going to hold the Uri to the Project Server front-end routing service and binding is the binding we use to connect to the Project Server front-end service.

I have adorned the ReadTimesheetListForCurrentUser method with an operation behavior that specifies that impersonation is required for this method. This is because I want to retain the identity of the caller of my extension service when I call Project Server. The method includes the actual calls that are to be aggregated. First I call the Resource business object to get the unique ID of the calling user, and then I call the Timesheet business object to retrieve the timesheet list for the calling user. You may want to allow the caller to specify the range of the timesheet list in more flexible way in your production code.

Finally, after retrieving the dataset that contains the timesheet list, I read the XML representation of that dataset and return it to the caller. To make this work, I use a few helper functions which I will go through now. First, I use CreateClientChannel<T> to ease the work associated with getting a channel to the targeted service. T is the “shape” of the channel, or the interface type you are using. The helper function looks like this:

private static TChannel CreateClientChannel<TChannel>()

{

   var channelFactory = new ChannelFactory<TChannel>(

      Binding,

      new EndpointAddress(ServerUri));

   channelFactory.Credentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation;

   return channelFactory.CreateChannel();

}

The helper internally makes use of two properties, Binding and ServerUri, which are just the variables explained above exposed as properties with a lazy initialization pattern on top of them. Note that in production code, you’ll probably want to cache the ChannelFactory<T> because that is the most expensive object to create. The methods used to lazily initialize the two Binding and ServerUri properties are written like this:

private static string GetServerUri(HttpContext context)

{

   var schemeAndServer = context.Request.Url.GetComponents(

      UriComponents.SchemeAndServer,

      UriFormat.SafeUnescaped);

   var requestUrl = context.Request.Url;

   int portNo = 80;

   var portString = requestUrl.GetComponents(UriComponents.Port, UriFormat.SafeUnescaped);

   if (!string.IsNullOrEmpty(portString))

   {

      portNo = int.Parse(portString);

   }

   var uriBuilder = new UriBuilder(

      requestUrl.GetComponents(UriComponents.Scheme, UriFormat.SafeUnescaped),

      requestUrl.GetComponents(UriComponents.Host, UriFormat.SafeUnescaped),

      portNo,

      context.Request.RawUrl.Replace("Service.svc", "ProjectServer.svc"));

   return uriBuilder.Uri.ToString();

}

private static BasicHttpBinding GetServerBinding()

{

   var serverBinding = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);

   serverBinding = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);

   serverBinding.AllowCookies = true;

   serverBinding.MessageEncoding = WSMessageEncoding.Text;

   serverBinding.TransferMode = TransferMode.StreamedResponse;

   serverBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Ntlm;

   serverBinding.Security.Transport.ProxyCredentialType = HttpProxyCredentialType.Ntlm;

   serverBinding.Security.Transport.Realm = "foo.acme.com";

   serverBinding.MaxBufferSize = int.MaxValue;

   serverBinding.MaxReceivedMessageSize = long.MaxValue;

   serverBinding.ReaderQuotas.MaxArrayLength = 50000000;

   serverBinding.ReaderQuotas.MaxNameTableCharCount = 5000000;

   serverBinding.ReaderQuotas.MaxStringContentLength = 640000;

   serverBinding.ReceiveTimeout = TimeSpan.FromHours(1);

   serverBinding.OpenTimeout = TimeSpan.FromHours(1);

   serverBinding.SendTimeout = TimeSpan.FromHours(1);

   return serverBinding;

}

As always, the code is provided as-is: not tuned for performance nor made robust to handle failures. In production code, you’ll probably want to use different sizes for the maximum buffer size, etc. Also, make sure your security parameters match what your setup has.

Now, at the end of the post, let’s just throw together a client that can call our extension service. It turns out that this task is extremely simple: We have all the parts needed. Start a new console project, and add a reference to System.ServiceModel. Copy the declaration of the contract (IExtensionPSIService) into your client project. This is one of the really cool things about WCF: it does not have to be the same type, as long as the types are wire-compliant. To us, this means that you can have the interface in a totally different assembly as long as the operations and their signatures (and also SOAP namespaces – a feature that we have not used here) are the same. You’ll also need a way to create a binding; for this purpose, you can just copy the code that we have in the extension service. Your client now looks like this:

static void Main(string[] args)

{

   IExtensionPSIService channel = null;

   var binding = CreateCustomBinding();

   try

   {

      var channelFactory = new ChannelFactory<IExtensionPSIService>(binding);

      channelFactory.Credentials.Windows.AllowNtlm = true;

      channelFactory.Credentials.Windows.AllowedImpersonationLevel =  TokenImpersonationLevel.Impersonation;

      channel = channelFactory.CreateChannel(

         new EndpointAddress("https://<servername>[:port]/pwa/_vti_bin/PSI/Service.svc"));

      var result = channel.ReadTimesheetListForCurrentUser();

      Console.WriteLine(result);

   }

   catch (Exception e)

   {

      Console.WriteLine(e.Message);

   }

   finally

   {

      ((IClientChannel)channel).Close();

      ((IClientChannel)channel).Dispose();

   }

}

Easy, eh?

So, why I am writing this all over again? Well, the answer is that things have changed since the release of Office 2007. I will not go into all details, but two changes stand out: claims authentication and WCF. Over the course of the Microsoft SharePoint Foundation 2010 and Project Server 2010 release, the internal authentication infrastructure was changed to claims. A whole slew of very cool scenarios are now enabled by claims authentication. For Project Server, this means that all back-end services –the PSIs – are now placed in an access control list (ACL)  by using claims. Checking the ACL is done by an entity referred to as “the gatekeeper”. The gatekeeper inspects the set of claims that travels along with the request, and if satisfied the gatekeeper allows the service invocation to occur. If not, the service invocation request is rejected. Secondly, using claims as the authentication mechanism mandates that WCF is the transport infrastructure as it is impossible to associate a claim with a regular ASMX web service call.

The primary change from Project Server 2007 and Project Server 2010 is mandated by the introduction of claims: Since all services on the backend are now ACL’ed using a claim (via the gatekeeper), if you were to call a service on the backend directly, you’d have to obtain a set of claims describing you the calling entity. This is certainly doable, but not trivial: It requires you to make a call to a suited STS and obtain the produced claim and associate it with the request you are about to make to the backend. So, to make this easier for you, we have changed the way you deploy PSI extensions. In this multi-part post, I will explain how to make a PSI extension service that lives and breathes under Project Server 2010. In this first part, I will get the skeleton service up and running and in the next part, I’ll try to actually do something useful with the extension service and also get a client working. Finally, I’ll try to illustrate what the changes are between a 2007 extension and a 2010 extension and hopefully give some guidance on what needs to change for a 2007 extension to be migrated to a 2010 extension.

PSI Extension Skeleton using Project Server 2010 – Part I

Because of the changes in the authentication and authorization infrastructure that occurred during the development of Office 2010, PSI extensions now are deployed on the front-end. Since the extension service will be a WCF service, a couple of things (configuration items) have to be accomplished in order for your service to be functional as a WCF service. The mantra to use when developing WCF services is A-B-C, or Address, Binding and Contract. In short, the address designates where the service is reachable, the binding determines transport properties like transport type, message size etc., and the contract defines what a request and a suitable response for the actual service operation looks like.

One of the really cool features of WCF is that many properties of your service are governed by configuration files so that you can focus on writing your business logic without having to worry about the infrastructure that makes it all possible. To that end, we will take care of the address and the binding in the configuration file that governs the front-end. Finding that particular configuration file can be accomplished in several ways – I have chosen to use PowerShell this time. The following script gets you the exact location of the configuration file we are interested in:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Administration") > $null

$serverManager = New-Object -TypeName Microsoft.Web.Administration.ServerManager

$site = $serverManager.Sites["SharePoint - 80"]

foreach($app in $site.Applications)

{

   foreach($vdir in $app.VirtualDirectories)

   {

      $outputPath = $vdir.PhysicalPath + "\PSI\web.config"

      if([System.IO.File]::Exists($outputPath))

      {

         Write-Host $outputPath

      }

   }

}

$serverManager.Dispose()

$serverManager = $null

If all works out well, the previous script (you may have to run it in a PowerShell  prompt with elevated privileges) should output the path to the configuration file that governs the PWA front-end. Note, you will most likely have to replace the site name (“SharePoint – 80” in my case) with what you have called your default SharePoint site.

Now, open the web.config file of the site, and make a few changes to the file. First, you’ll need to define what bindings your extension service will be using. Keep in mind that this will have to be compatible with the bindings configured for the SharePoint site that hosts your PWA. For the sake of this example, the binding entries, which go into the <system.serviceModel> section, look like this:

<bindings>

  <basicHttpBinding>

    <binding name="extensionBasicHttpConf"

             closeTimeout="00:01:00"

             openTimeout="00:01:00"

             receiveTimeout="00:10:00"

             sendTimeout="00:01:00"

             allowCookies="true"

             maxBufferSize="4194304"

             maxReceivedMessageSize="500000000"

             messageEncoding="Text"

             transferMode="StreamedResponse">

      <security mode="TransportCredentialOnly">

        <transport clientCredentialType="Windows" proxyCredentialType="Windows" realm="" />

      </security>

    </binding>

    <binding name="mexHttpBinding">

      <security mode="TransportCredentialOnly">

        <transport clientCredentialType="Windows" proxyCredentialType="Windows" realm="" />

      </security>

    </binding>

  </basicHttpBinding>

</bindings>

Note that you may not need to be using streamed responses and your timeouts should probably be a little more aggressive than what I have shown above. While developing the extension service, it may also be useful to you to have a service behavior that allows exception details to be populated into any fault that may occur. The following XML in the <system.serviceModel> section shows how to implement the fault behavior:

<behaviors>

  <serviceBehaviors>

    <behavior name="PSIExtensionServiceBehavior">

      <serviceDebug includeExceptionDetailInFaults="true" />

      <serviceMetadata httpGetEnabled="true" />

    </behavior>

  </serviceBehaviors>

</behaviors>

Finally, you’ll have to declare the extension service in terms of address. Here is the XML (again in the <system.serviceModel> section):

<services>

  <service name="Project.Server.Extensions.ExtensionPSIService"

           behaviorConfiguration="PSIExtensionServiceBehavior">

    <endpoint address=""

              binding="basicHttpBinding"

              bindingConfiguration="extensionBasicHttpConf"

              contract="Project.Server.Extensions.IExtensionPSIService" />

    <endpoint address="mex"

              binding="basicHttpBinding"

              bindingConfiguration="mexHttpBinding"

              name="mex"

              contract="IMetadataExchange" />

  </service>

</services>

With this addition to the config file, we have now declared the address that the extension service will be listening to, we have declared what binding will be used and finally we have the contract exposed by the service. Additionally, we have a metadata exchange (MEX) endpoint – useful for creating clients. This is something that you may or may not want in a production environment.

The next thing to do is to create the activation file. This is the file, when requested will initiate the activation of your service. By default, this file is called <service name>.svc and is placed in the same location as the web.config file that holds the configuration entries for the service. Note that the name you chose for the activation file is what you will be putting in the request URL when you try to access the service. I have named mine Service.svc, with the following content:

<%@ServiceHost language="C#"

               service="<Fully qualified type name>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=<PublicKeyToken of your assembly>" %>

PSIExtensions is the name of the assembly that holds the service implementation. As you can see, I have strongly signed the assembly and put it in the GAC.

With all the configuration work behind us, we can now write the actual service. This will be the topic of the next part of this post, but for now I will explain how to get the skeleton up and running. In Visual Studio 2008 or Visual Studio 2010, create a new class library (you may also use the template to create a WCF service library – I typically do not because it creates more files than I need, and I like to be in total control as to what goes where).

Add a reference to System.ServiceModel for your class library, and add a new code file that will have the interface definition. It should, for now, look like this:

namespace Project.Server.Extensions

{

   [ServiceContract]

   internal interface IExtensionPSIService

   {

      [OperationContract]

      string EchoHello();

   }

}

Now, all we need is to have the actual service implementation. For that, add a new class to your assembly with the following content:

namespace Project.Server.Extensions

{

   [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

   internal class ExtensionPSIService : IExtensionPSIService

   {

      #region IExtensionPSIService Members

      public string EchoHello()

      {

         return "Hello";

      }

      #endregion

   }

}

The AspNetCompatibilityRequirements attribute is needed as the web application that hosts your extension service (and the Project Server front-end service) requires ASP.NET compatibility – if you omit this attribute declaration, your service cannot be activated.

You should now be able to compile, register in the GAC, and activate the service. Open a browser and target the service activation file that you created. In my case, since I have deployed PWA in a “sub-site” called PWA, the URL looks like this: https://<servername>/pwa/_vti_bin/PSI/Service.svc (assuming that you have your PWA instance in an app called “pwa” – please update your URLs accordingly if that is not the case).

You should be getting the well-known “You have created a service.” page.

"The server committed a protocol violation. Section=ResponseBody Detail=Response chunk format is invalid"

For the longest time I had no clue as to what was going on. I tried searching the web, but I found very few (only a hand full, I think) references, and none of those references seemed to make sense in my context (actually, I am hoping that this post will get indexed such that people facing the same may hit this post and maybe be helped out. I know... The good samaritan!). I tried enabling tracing, but I didn't see anything that jumped out at me. It has to be said, though, that I am by no means a master at reading those traces. I tried using Fiddler, but for some reason that caused to halt the response from my service to the client -- I still have to work out why that is. I tried with Network Monitor, but I drowned in the sea of frames it reported.

I enlisted the help of some of the people in the WCF framework team, and pretty quickly, we got some traction. The first thing that stood out was that the communication between client and the server was chunked. In the HTTP 1.1 spec, it states that if you use chunking, you (the server) has to provide the chunking length. In my case that was missing. After further input from the WCF people, the solution was very simple: Before returning the message to the client, simply clear all properties on the message (using Properties.Clear() on the message in question).

I hope this will help those of you who are unfortunate enough to run into this one.

EDIT: After talking a bit more to the people in WCF, it turns out that this is most likely expected behavior. See this MSDN article, specifically the "Working with Properties" section. Specifically, this sentence explains it:

"Normally, property values do not map directly to any part of the message on the wire, but rather provide various message processing hints to the various channels in the WCF channel stack or to the CopyTo service framework"

I like the way I am being brough back to the school bench while the simples concepts are explained eloquently and efficiently. Then, as you turn each page, things get progressively more complex in such a well thought out stream of info. Get it. Read it. Enjoy it!

In all simplicity, most of the heavy lifting will be done by FSX/ESP for rendering the outside views from the cockpit and doing the physics calculations that are needed to model flight. I am most likely not hooking up extra hardware (interface boards, that is) to the box that runs FSX/ESP. This is despite the fact that I wrote a small app to poll the joystick at a certain frequency (it varied in my tests from 10 Hz to 60 Hz) just to see what the cost of such an app would be in terms of resource usage. It was barely noticable! I don't know if that is because I used CCR or not, but one thing is sure: CCR made it extremely easy to write. I ran this app on a dual core. I forget what the specs of that box is, but it is a fairly old Dell Dimension 9100 with 2 Gb RAM.

Continuing this train of thought: I think the boxes that will actually be running the interface software will be the cheapest boxes I can find online. I looked at assembling such a box from spare parts found online, and the tally came out to be about $200. With prices like that, it seems that the over all cost of this little project will come from knobs and switches that make it look like the real thing, not from the computers that do the hardware I/O (with the exception of the main FSX/ESP computer, which I hope will be a beast of dimensions).

The code that runs the polling of the joystick is given below. Again, the Interleave arbiter is your friend (or, mine at least. You could potentially rewrite this using other constructs, I have just come to love the Interleave arbiter with all my soul).

So, it arrived. I immediately sat down to look at the managed API that works with this board. The API lends itself easily to use with CCR. Especially, part of it was almost a text book example of the Interleave arbiter. The story is this: When your app starts, you need to start an instance of a manager object. This manager object exposes a couple of events that notify interested parties when interface boards are attached or detached. Each of the interface boards that the manager manages, in turn has their own events when, say, input to the board or output from the board changes. This leads to the following Interleave arbiter groups:

TeardownReceiverGroup failureOrCompletionGroup = new TeardownReceiverGroup(

  Arbiter.Receive<ErrorEventArgs>(false, errorPort, error =>

  {

    // Handle errors

  }),

  Arbiter.Receive<TaskStop>(false, taskStopPort, taskStop =>

  {

    // Handle normal shut down

  }));

ExclusiveReceiverGroup exclusiveGroup = new ExclusiveReceiverGroup(

  Arbiter.Receive<AttachEventArgs>(true, attachPort, attachEventArgs =>

  {

    // Do what is needed to record that the manager has found a board

  }),

  Arbiter.Receive<DetachEventArgs>(true, detachPort, detachEventArgs =>

  {

    // Do what is needed to handle the fact that a board has been detached

  }));

ConcurrentReceiverGroup concurrentGroup = new ConcurrentReceiverGroup(

  Arbiter.Receive<OutputCommand>(true, outputCommandPort, outputCommand =>

  {

    // Set an output port to true...

  }),

  Arbiter.Receive<InputChange>(true, interfaceKitPort, inputChange =>

  {

    // Handle an input change...

  }),

  Arbiter.Receive<OutputChange>(true, interfaceKitPort, outputChange =>

  {

    // If you need to do some processing once the output has changed

  }));

Arbiter.Activate(dispatcherQueue, Arbiter.Interleave(failureOrCompletionGroup, exclusiveGroup, concurrentGroup));

ErrorEventArgs, AttachEventArgs and DetachEventArgs are taken directly from the API of the board producer. TaskStop is just an empty class I created that I can post the port used in the second receiver in the failureOrCompletionGroup. In the exclusiveGroup, what I do is to keep track of the boards that are currently attached. The sweetness is that I can have a dictionary into which I insert entries in the AttachEventArgs receiver and from which I remove entries in the DetachEventArgs receiver totally without having to have synchronization primitives because the exclusive group guarantees exclusiveness from other receivers in the group and from receivers in the concurrent group.

The concurrent group is rather straightforward: I have a receiver for OutputCommand instances, which are commands sent by the application when it wants set an output to true. The InputChange receiver handles the case when an input has changed on a board, and the OutputChange receiver handles the feedback that comes back when an output has changed.

Finally, all that is left to do is to activate the Interleave arbiter as shown in the last two lines of code.

Isn’t CCR just too sweet to not use?

I have been toying with the idea for many, many years but I have always been discouraged (or, read: prevented) by the cost of hardware/software that would live up to my expectations for such an undertaking. For a long time, there was really only one provider of software (this is discounting us -- Microsoft -- as we seem to be the platform for all these projects) and only one or two providers of hardware (not so much computer hardware, but panels and replicas) that could give you sort of building block approach to this. This has changed in the favor of the cockpit builder.

I think the final push came when I found out that we now offer a simulation platform in ESP. As an MSDN subscriber, I have access to the bits, and I have installed them at home. I am hoping that this will be a great way to combine at least two of my primary hobbies: Aviation and software design/development. Now that I have an [easy] way of writing software for the flight simulator myself, I can combine that with the drop in hardware prices and finally start to realize my dream. For instance, there should be nothing to prevent me from getting an IO card, from any of the many vendors that exist, and hooking that up to a stepper motor, write the software to read the variables in ESP et voíla we have a vertical speed indicator that is an actual piece of hardware and can be mounted in a frame that will eventually become a cockpit. This, of course, sounds much easier than it probably is -- especially considering that I am no mechanical/electronics whizz. I figure I will either learn along the way, or die trying.

So, now that this is out of the way, I guess there are only a few more questions to ask and answer: What type of cockpit will I be building? I am torn here. It is going to be a jet, and a short/medium haul. I am interested in the take-off and landings, not so much the cruise where most of the time is spent as an observer monitoring systems -- with that said, I guess the most obvious is short to medium haul. Within this genre, the battle is between Airbus A319/A320/A321 and Boeing 737NG (-600, -700, -800, -900). Trying to be totally unpolitical about it, I would argue that each plane has its advantages. I really like the philosophy behind Airbus, but at the same time, Boeing just hit the nail on the head with the 737. From a hardware (panels, switches etc) standpoint, I think the Airbus is probably easier -- just think of what it would take to make throttle levers for a B737 throttle quadrant with throttle levers that move in response to commands from the autopilot (or, MCP in Boeing speak), or dual linked control yokes that have "force feedback". On the other hand, I think it would be harder to write the software to control an Airbus because of the many laws that govern the Airbus (I can think of normal law, alternate law and direct law. Other laws may exist that I am not aware of yet).

Anyway, it is out now. This is the thing that I alluded to in one of my previous posts. Now, I am slowly starting to move along. Stay tuned.

Basically, the idea is that you in your class you have a Finalizer and the Dispose method. In your Dispose method, you do what you would normally do and you call GC.SuppressFinalize(this). All of this happens within a #if DEBUG ... #endif.

* There may be others, but with SafeHandle I can't think of many places where you would need to keep explicit track of unmanaged resources.

** Through all my years in university, I always hated when professors would leave interesting points as exercises left to the reader. If you are trying to drive a point, make sure that it is not left to chance if you get it across or not. However, I have waited many years to use that same sentence, so here it is. 

 Stay tuned (just not to Thomas and Friends).