I’ve been meaning to get around to writing this post for a wee while, but finally Vish’s post on AGS logging has prompted me to actually do it. I should begin by crediting a friend who put me onto this tip for debugging Server Object Extensions (SOE) because it has saved me a great deal of time!
So as Vish mentions debugging SOE’s can be a bit tricky and up until a few months ago I took a combined approach:
1. Write the core SOE functionality remotely first before porting it to a SOE to make sure that my logic was basically ok
2. Logging using the ILogSupport interface.
This approach is very time consuming especially the first step, so it was a relief to find that through attaching to the SOC process which was hosting the SOE from within a live debug session in Visual Studio allowed me to step into the SOE and debug it directly! Here’s a walk-through:
1. Firstly stop all the services you don’t want to debug within AGS – this can be done via AGS Manager or ArcCatalog.
2. Configure the service you wish to debug so that it only has a single instance runningÂ – this can be done by looking at the service properties and setting the minimum number of instances to one. By doing this it helps to isolate the correct process to attach to when debugging:
3. Ok now open your project/solution in Visual Studio – usually I include the SOE into a solution with the SOE client, so for example I have a console application that creates a connection a web service which in turn connects to AGS:
private ESRI.ArcGIS.ADF.Connection.AGS.AGSServerConnection agsconn = new ESRI.ArcGIS.ADF.Connection.AGS.AGSServerConnection(); private ESRI.ArcGIS.Server.IServerObjectManager serverManager; private ESRI.ArcGIS.Server.IServerContext sc = null; private ESRI.ArcGIS.Server.IServerObject so; private ESRI.ArcGIS.Server.IServerObjectExtensionManager soexm; private ESRI.ArcGIS.Server.IServerObjectExtension soext; private soe.LrsServerObjectExt localSoe;//create a connection to the gis server agsconn.Host = "pc302926"; agsconn.Connect(); //create a context serverManager = agsconn.ServerObjectManager; sc = serverManager.CreateServerContext(mapServer, "MapServer"); //get the soe so = sc.ServerObject; soexm = (ESRI.ArcGIS.Server.IServerObjectExtensionManager)so; soext = soexm.FindExtensionByTypeName(soeName); //create a local instance of the soe localSoe = (soe.LrsServerObjectExt)soext; return localSoe.getThroughDistanceIndex(asset.X, asset.Y, 10);
4. In the code here the web service connects to AGS and a local instance of the SOE is created for use by the web service.
5. Create a breakpoint at a suitable point before the SOE is actually called – in the sample above perhaps the ‘localSoe = (soe.LrsServerObjectExt)soext;’ might be a good point.
6. Place another breakpoint at the entry point of the SOE itself (not shown above)
7. Run the code in debug mode ensuring that your client is set as the start up project and wait for the first breakpoint to be hit
8. Once it hits the breakpoint, in Visual Studio launch the Attach To Process window (debug>attach to process):
9. Ok now you can attach to the SOC instance which is hosting your SOE (the single instance you configured in step 2) – there will be a number of SOC instances available – the instance you want to attach to is the managed instance (if you didn’t choose to do step two and you have multiple SOC processes running then you may want to attach to them all.) I also find that process explorer is handy for isolating the correct service – AGS automatically utilises two SOC processes for managing itself therefore with a single service running with a single instance you should have three SOC processes running – two dedicated to the server itself and a third which is being used by the service. When using process explorer ensure that the lower pane is visible (view>show lower pane CTL>L) by selecting a process the lower pane will display properties – the SOC process which is dedicated to the service will appear with a lot more properties than those being used by AGS itself.
10. So now you can continue to step through the code and you should step into the SOE itself
This is helpful at development time, but obviously it doesn’t preclude the use of logging as per Vish’s post. Another step which can help when debugging SOE based applications (but not actually debugging the SOE itself) is to ensure that the Visual Studio does not attempt to build the SOE each time you begin debugging. You can configure this via the Configuration Manager within Visual Studio(Project>Configuration Manager). The reason that this is useful is that if you attempt to build the SOE each time you begin to debug you’ll find that the AGS SOC process holds a lock onto the SOE assembly and you will be unable to complete a build forcing you to stop the service before building which is a bit tedious if you are not actually debugging the SOE.