Navigation

Home

Search

Categories

On this page

Generics Based .NET Remoting Event Shim
SMTP Event Sink Registration Problem

Archive

November, 2007 (4)
October, 2007 (1)
April, 2007 (2)
February, 2007 (1)
December, 2006 (1)
November, 2006 (6)

Blogroll

 Aaron Skonnard
 Brad Abrams
 Christian Weyer
 Clemens Vasters
 David Chappell
 David Yack
 Don Box
 Eric Newcomer
 Grady Booch
 Ingo Rammer
 Joel Spolsky
 Jon Flanders
 Matt Brown
 Mike Taulty
 Paul Andrew
 Rob Howard
 Sam Gentile
 Scott Colestock
 Scott Guthrie
 Scott Hanselman
 Scott Woodgate
 Udi Dahan
 Yasser Shohoud

Disclaimer
None - these are my opinions and they're also my employer's!

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 14
This Year: 0
This Month: 0
This Week: 0
Comments: 15

Sign In

 Saturday, April 21, 2007
Generics Based .NET Remoting Event Shim
Saturday, April 21, 2007 9:10:14 PM (Mountain Daylight Time, UTC-06:00) ( )
I built a Windows service to host different processors that work with MSMQ. Each processor is running in its own AppDomain and needs to fire events to the host service. .NET remoting is used to wire up the connections between the host process and the processors as a result of the cross appdomain communication requirement.
 
Handling events in this scenario requires a handler or shim to be used to avoid requiring a reference to the event subscriber in the event publisher. The shim is simply a broker or proxy for both sides. I tried to find an example of one that used generics but was unable to so I decided to come up with one. It's essentially wrapping the built-in generic EventHandler<T>. This allows any event argument type to be passed as T.
 
Here's the code: 
 
   [Serializable]
   public class RemoteEventShim<T> : MarshalByRefObject where T : EventArgs, new()
   {
      public override object InitializeLifetimeService()
      {
         return null;
      }
 
      public event EventHandler<T> RemoteEvent;
 
      public void RemoteEventHandler(object sender, T e)
      {
         EventHandler<T> handler = RemoteEvent;
         if (handler != null)
         {
            handler(sender, e);
         }
      }
   }
Comments [0] | | # 
 Tuesday, April 10, 2007
SMTP Event Sink Registration Problem
Tuesday, April 10, 2007 7:31:52 AM (Mountain Daylight Time, UTC-06:00) ( )

I seemed to have hit a quirk in the registration of event sinks in the SMTP service.  As I discussed in this previous post, I had a need to create a managed SMTP event sink and worked out all the kinks in using that to send to a local MSMQ.  Everything has been running great.

However, I needed to install a new version in a side-by-side mode and couldn't for the life of me get the second assembly to load after registering it with the smtpreg.vbs utility.  I tried everything I could think of but nothing seemed to work.  In order to even register I had to create the new version with a different class name so the ProgID would be unique.  I also had to change the ComVisible attribute Guid property so that I would have a new ClassID.  All of this was pretty obvious.  But even after making sure things looked fine in the registry and the IIS metabase (the actual SMTP sinks are all located in the metabase,) I couldn't get my event sink to fire.  I was even registering using a unique name for the registration entry by appending a 2 to the name (e.g. SMTP2MSMQ2 vs. SMTP2MSMQ.)

I had just about given up when I thought I would try prefixing the version to the registration name vs. appending it.  It worked!  I haven't spent any more time (I had already spent way too much time on this) to figure out what the heck was going on but left it up to some weird registration matchup logic due to the name beginning with the same letters.  You can register the same SinkClass multiple times to manage different patterns of email addresses, etc. but apparently the same name with different SinkClasses is a no-no.

Comments [2] | | #