Convention over configuration based services

Topics: Developer Forum
Apr 13, 2008 at 12:01 PM
I tried to create services using the SDK templates provided for VS2008 and despite I use the same folder specified in the documentation "C:\ESB\DEV\Source\ESB\LobSystems\ns", I could not get it right.

No assembly references were added and even if I add them manaully I can't see the handler in the managment console.

I'm using the latest release

One more thing, I appretiate if you can provide a step-by-step guidance to demonstrate
  1. how to create a service handler
  2. how to configure the pipeline for that handler to use WCF Transport handler
  3. how to send requests from a client

Thank you in advance.

Apr 15, 2008 at 12:09 PM
Sorry for the delayed response. Trying to get this release out. Issues uploading!!! Seems to timeout after 10 minutes or so.
Anyway, things to check are:

1)Are you using VS.NET 2008? The version 6.x of ESB.NET is built around VS.NET 2008 and .NET 3.5.
Whilst on PreRequisites, you'll also require WSE 3.0 to have the complete functionality, so please ensure that's installed as well.

Download from:

2)The SDK has changed slightly in the latest release ( The SDK should work regardless, but this release will make the developer
experience a lot better for creating and submitting requests. The basic tutorial will be updated to reflect this
(as soon as I manage to upload the actual release!).

3)Can you please check that there are assemblies in the following directories:






If so, are the assembly references pointing to them correctly?

Also, please ensure you DON'T check the "Create Directory For Solution" option.
Your directory structure should look something like:



i.e. similar to the rest of the projects in that directory.

Note that:
i)The requirement to have assemblies in this directory is only for Convention Based Services.
Configured Services can be anywhere, although you may still need to adjust the project references if the directory differs.

ii)The current convention over config adaptor assumes the above directory structure, as does the ESB Management Console (EMC).
The source is available to change these, although in one of the next few releases, this will likely be made a config setting.

4)In any case, if the above assemblies are in place in the above directories, and you're still having issues, then the easiest way to add them is to

add the following directories to your project references paths:

let me know if this resolves your problem.

Depending upon the issue, we may have yet another RC :(.

Hope this helps.
Apr 15, 2008 at 12:25 PM
On your questions re:
- how to create a service handler
==> There is a simple tutorial you can download that covers the most basic steps at the moment. They will be fleshed out more soon (well, as soon as I manage to upload the release!).

- how to configure the pipeline for that handler to use WCF Transport handler
==> By default, all services are available from all Transports. You don't need to do anything.
If you like, you can build an Authorization Handler to inspect the request and transport, and allow/disallow accordingly.
This is a planned Handler for the medium term.

- how to send requests from a client
==>Again, this will be fleshed out in one of the next set of tutorials.
Briefly though, there are 2 options here.
1)View the ESB.NET Management Console code.
It uses the ESB.NET RequestHandlerProxy component
which is the recommended way for server applications to communicate with ESB.NET. ESB.NET uses this component itself when invoking/routing messages.

2)Use a standard WSDL, point-n-click type client. (Not recommended at this point).
The WSDL's are not currently fleshed out very well, and you'll just get a generic looking WSDL that provides an interface similar to what the RequestHandlerProxy component does.
In future releases, an additional BSDL==>WSDL XSLT will be made available, to be used in conjunction with the
and a similar WCF hosted Endpoint, which will handle requests generated by clients using the dynamically generated WSDL's.

3)Note: Another feature of ESB.NET is that it can (using the ESBHTTPGenericWebServiceTransport.aspx) transparently proxy existing web services. It does this by inspecting the request.
In ESB.NET, by configuring the ServicePipeline, you can add generic processing (via way of an Always Execute handler for example), or handle specific services.
This is currently a side-feature, but again will be fleshed out over time.
It adds yet another dimension to the Service Virtualization capabilities of ESB.NET.
Apr 15, 2008 at 2:55 PM
Edited Apr 15, 2008 at 2:56 PM
Thank you for the valuable response.

Trying to get this release out. Issues uploading!!! Seems to timeout after 10 minutes or so.

This is always the case :-) , hope you can resolve this issue soon.

1)Are you using VS.NET 2008? The version 6.x of ESB.NET is built around VS.NET 2008 and .NET 3.5. Whilst on PreRequisites, you'll also require WSE 3.0 to have the complete functionality, so please ensure that's installed as well. Download from:

all the prerequisites installed.

2)The SDK has changed slightly in the latest release ( The SDK should work regardless, but this release will make the developer experience a lot better for creating and submitting requests. The basic tutorial will be updated to reflect this (as soon as I manage to upload the actual release!).

I will wait for this release and then get back to you.
Apr 15, 2008 at 3:07 PM
Edited Apr 15, 2008 at 3:08 PM
1)View the ESB.NET Management Console code.

I already did but an exception is thrown whenever I call the ProcessMsgSync function.
In case you are interested in helping me which will be appreciated, here is my code and the stack trace

XmlDocument xr = new XmlDocument();
string xml = xr.InnerXml;
IEnvelope oEnv = new Envelope();
oEnv.XML = xml;
oEnv.SetCustomParam(ESBConstants.C_sClientNumExecutionTimes, "1");
ESB.Core.Adaptors.Transport.RequestHandlerProxy.Sender server = new Sender("http://localhost/ESB/Source/CoreInternetTransportAdaptors/Wcf/ESBSoapXmlDocTransport.svc/Default", "SOAP", "ESBSoapXmlDocTransportSoap");
xml = oEnv.XML;
IEnvelope res = server.ProcessMsgSync(oEnv);

Exception : "Value cannot be null. Parameter name: path1"

Stack Trace:

at System.IO.Path.Combine(String path1, String path2)
at ESB.Core.Util.Utils.ExpandRelativePath(String& sPath, String& sRootPath)
at ESB.Core.Services.ContextManager.getContextManager(Boolean bServerContextManager)
at ESB.Core.Adaptors.Transport.Send.Wcf.ESBSoapXmlDocTransportWcfSender..ctor()
at ESB.Core.Adaptors.Transport.RequestHandlerProxy.Sender.GetSendTransportAdaptor(String& sAddressType)
at ESB.Core.Adaptors.Transport.RequestHandlerProxy.Sender.ProcessMsgSync(IEnvelope oEnv)
at ESBNET.Test.Client1.Form1.button1_Click(Object sender, EventArgs e) in C:\ESB\DEV\Source\ESB\Base\Solutions\Main\Management\ESBNET.Test.Client1\ESBNET.Test.Client1\Form1.cs:line 39
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
at ESBNET.Test.Client1.Program.Main() in C:\ESB\DEV\Source\ESB\Base\Solutions\Main\Management\ESBNET.Test.Client1\ESBNET.Test.Client1\Program.cs:line 18
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Apr 15, 2008 at 9:15 PM
This will be covered in a Tutorial on using the RequestHandlerProxy class.
OK, This is why you're getting that error:
Basically, you need to tell the client where the root of the application is. Config files and other things use this.
Note that there is a Client Contet Manager that gets setup when using the RequestHandlerProxy.
It gives you some flexibility in terms of plugging into your logging etc. frameworks.
As there are many classes that are used in both client and server mode, this is necessary to allow re-use & ensure flexibility when working within client frameworks.

As well as this, there are the configuration files that you require. These ones are required:


The following line gets the Base Path of your app.
==> at ESB.Core.Util.Utils.ExpandRelativePath(String& sPath, String& sRootPath)

If you look at the ESB Management Console, on the following event Application_Start in:

Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
' Fires when the application is started

'Set the ESB Root Path on the ServerContextManager
'Dim oDIESB As New System.IO.DirectoryInfo(Server.MapPath(""))
Dim oDIESB As New System.IO.DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory)

'Go up 5 levels to the ESB Root Path...
Dim sESBRootPath As String = oDIESB.Parent.Parent.Parent.Parent.Parent.FullName '& "\"
ESB.Core.Util.ESBGlobalVariables.ESBRootPath = sESBRootPath

End Sub

The reason for this is that ESB.NET does not follow the rule of:
Everything runs within the single IIS Virtual Directory.
There is configuration that is shared amongst transport adaptors.
As such, there is a concept of an ESB Root directory.
In order to allow EVERYTHING else to be relative, the hosting process needs to explicitely set where the ESB Root is.
This is a hangover from sharing client & server side code.
Whilst this is generally not a big deal on the server side, or on large clients that have only one host, it gets in the way of small/quick client apps, and unfortunately gives you the grief you've just experienced.
This is partly why
- a tutorial is needed
- some simplification is required
for client apps.

As soon as I get this latest build sorted, I'll put up a quick tutorial.

Apr 16, 2008 at 11:01 AM
Edited Apr 16, 2008 at 11:53 AM
Apr 16, 2008 at 11:08 AM
woo ow, it worked, it's awesome

thanks to
please ensure you DON'T check the Create Directory For Solution option.

I can create Convention over configuration based services without adding the assemblies manually, and I can see it in the management console

Thank you so much for the gratefully explanation
Apr 16, 2008 at 11:06 PM
OK, Release seems to have uploaded now...
Thanks all for your patience.