GenericMessaging updates via SVN

It’s been a while since I’ve done anything with the GenericMessaging project which is too bad since I consider it to be the most useful of the projects that I have been working on lately. Last week I ran into a painful brick wall regarding the security system I’ve been working on, so I decided to do some reworking on GenericMessaging while my brain sorts itself out and develops new neural pathways to replace the fried ones. There have been several comments on the forum about GenericMessaging, mostly regarding its dependence on PostSharp. While I think that PostSharp is great, it’s probably not something that needs to be intimately linked with the GenericMessaging layer. I’ve abstracted PostSharp support out into its own separate library. I’ve also added a new library that contains a class that will dynamically create a proxy for you using the Castle Dynamic Proxy Generator. This should give users more flexibility. I’ve uploaded these changes to the svn repositories but I won’t update the binaries quite yet as there is some more refactoring that needs to take place. So go grab the latest version from svn and give it a whirl.

Oh and a big thanks to those people who have posted on the forum with suggestions.

2 Responses to “GenericMessaging updates via SVN”

  1. Steinar Dragsnes Says:

    Hi!

    Great news, I’ll take a look at it. I did spend a couple of evenings on reflection emit to generate a proxy of the client end point of the service contract (since it basically only looks up the method on the server end point), and I guess Castle can do this for me much better (somehow I got a strange runtime error, not much fun to debug emitted code). Is this the envisioned usage of Castle or do you have something else on your mind?

    Cheers,
    Steinar.

  2. Daniel Guenter Says:

    @Steinar
    Good to see you back. Yes I tried to get Reflection.Emit to generate a proxy for me at runtime but realized eventually that it was a lot of work that Castle could just do for me. Eventually the Relection.Emit solution would be preferred but right now this works, and unfortunately I haven’t had much time to just play around with this lately.

Leave a Reply