Shortening CustomCommand development time by using a proxy

One of the most time-consuming processes when developing with Hexagon G/Technology is creating custom commands. The usual development approach consists of the following iterative process:

  • Compile custom command
  • Launch G/Technology
  • Test custom command
  • Exit G/Technology
  • Modify custom command
During testing, only limited changes to the source code are allowed by the Visual Studio Edit and Continue function, effectively requiring multiple iterations of this sequence.

The process of starting and closing G/Technology can easiliy takeup multiple minutes and you need to close it because G/Technology will lock any assemblies containing your custom commands.

Customcommands are written in DotNet and therefore run in something called an “Assembly Domain”, in this case the G/Technology Assembly Domain. When you create a custom command loading other custom commands in its own assembly domain, dotnet will not load the same assembly again in fact creating a proxy. The following code snippet demonstrates this:

string assembly = @"c:\Program Files (86)\Intergraph\GTechnology\YourCustomCommand.dll";
byte[] assemblyBytes = File.ReadAllBytes(assembly);
System.Reflection.Assembly assemblyToLoad = Assembly.Load(assemblyBytes);

Type entryClass = assemblyToLoad.GetTypes().FirstOrDefault(t ⇒ typeof(IGTCustomCommandModal).IsAssignableFrom(t));
if( entryClass != null)
    IGTCustomCommandModal CCModal = (IGTCustomCommandModal)assemblyToLoad.CreateInstance(entryClass.FullName);

entryClass = assemblyToLoad.GetTypes().FirstOrDefault(t ⇒ typeof(IGTCustomCommandModeless).IsAssignableFrom(t));
if( entryClass != null)
    IGTCustomCommandModeless CCModeless = (IGTCustomCommandModeless)assemblyToLoad.CreateInstance(entryClass.FullName);

This snippet scans an assembly for a type implementing either interface ‘IGTCustomCommandModal‘ or ‘IGTCustomCommandModeless‘, which both can be found in namespace ‘Intergraph.GTechnology.Interfaces‘ and are needed to implement customcommands. If a type implements one of these interfaces, the proxy customcommand creates an instance of it loading it in the assembly domain.

When this approach is used to load custom commands, G/Technology will not lock the containing assemblies after closing the custom command, enabling much shorter development cycles.

The technique constists of 2 or more custom commands, the first one being the proxy, the second one being the custom command to be developed. Once the first customcommand is started, it will show a dialog where the assembly containing the custom command to be developed should be entered :

Proxy dialog

Some extra querying to the G3E_CUSTOMCOMMAND table allows to provide useful metadata as shown in the pop-up window.

Then attach the Visual Studio debugger and press ‘Launch’ and any breakpoint in your customcommand should be hit and it can be tested. Once done, detach the debugger, modify code, compile and attach again, etc., etc. :

Debugging session active

An example of a session using this technique this can be seen in this this youtube video, showing a debug session of a custom command called “Swap Inner Ducts” which will just show a dialog and a messagebox, but the important part is that the customcommand is changed, recompiled and executed again using the Visual Studio debugger without leaving G/Technology.

Youtube video

Sources can be downloaded from here.

Credits go to Jan Stuckens for initially coming up with this idea.

Thanks to Michaël Demanet and Didier de Bisschop from Proximus for use of their environment to test this technique.

Notes :

  • the proxy needs to be built with debugging information, else breakpoints in the target customcommand won’t be hit
  • All referenced assemblies need to be loaded
  • This technique has been used with assemblies containing a single custom command, assemblies with multiple custom commands where not tested
  • G/Technology version 10.04.2002.00035 was used to test this approach

Debugging G/Technology 10.2 with Visual Studio

In an earlier post Stephan mentions that it was not possible to debug G/Technology 10.2 in “edit and continue” mode. You could only attach Visual Studio to the G3E.exe and debug. But you cannot break the code and then make a small change. For every change you need to close G3E.exe, compile your project, start G3E.exe and attach Visual Studio again. When you try to start-up the 10.2 G3E.exe in debugging mode from Visual Studio we got the following error message:

Exception start debugging g3e.exe from visualstudio

But here is the way to do that. The first thing you have to do is adjust the G3E.exe.config located in the \GTechnology\Program directory. You should add the following three lines  after the <configuration> tag.

<?xml version="1.0?" encoding="utf-8" ?>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v2.0.50727"/>

After that you must adjust the Path-variable. Or check if the path is already set in you system settings. The following path needs to exist in the path variable for a 64bit environment it is: C:\Program Files (x86)\Common Files\Intergraph. If you are using a 32bit environment you should lose the (x86) part.

Set the path variable

After setting the path, it is important to reboot the machine! Now you can fully debug your applications in Visual Studio.

If you are not an administrator on you machine and cannot change the path variable for some reason, you could also add the path to your working folder in Visual Studio. But if you have multiple projects defined in Visual Studio, you should change this for all projects.

Debug, without admin rights

Debugging Netviewer serverside pages

If you need to build server side pages in Netviewer, changes are likely that you want to debug them. First thing to do is to change the output-path of your assembly to C:\Program Files\Intergraph\GTechnology\Program\GViewerApp\bin like in the following figure:

Visual Studio output path

This figure shows the properties page of a project, and while the path isn’t complete visible, it should be C:\Program Files\Intergraph\GTechnology\Program\GViewerApp\bin, the bin folder of your application. Next step to do is make sure that the aspx-page in the GViewerApp folder matches the one in your project. You can either copy it or even better create a symbolic link to your original source using the fsutil command (see notes for an example). If you now start a debug session using F5, your breakpoints won’t be hit because you are using the Visual Studio built in webserver which uses an url like http://localhost:1399/ and Netviewer is using IIS. You can check the url netviewer client is using is by entering a string like http://G01/GViewer directly into Internet Explorer, where G01 should be replaced by your server. If you entered the right url, the following screen shows up :

Intergraph Netviewer client url from Internet Explorer

netviewer from ie

If you then select ‘OK’, Netviewer client will start. In order to debug your serverside pages, you need to attach the debugger to the process which is serving http://G01/GViewer. This is process ‘w3pw.exe’ running with credentials as set in your application pool :

Intergraph Netviewer application pool

Netviewer application pool

The process to attach to is the w3wp.exe executable running with the credentials as set in the IIS application pool :

Visual Studio attach to process

Attach to process

As you can see, the username matches the identity in my application pool which is G01\Stephan. If you now start a debug session, breakpoints probably won’t be hit because there are some more steps we need to take care off. The next step is enable debugging in IIS :

Enable debugging Internet Information Services Windows Server 2003

Enable debugging IIS

This figure shows the ‘Configuration’ dialog of the GViewer-IIS node. You can reach this by opening Internet Information Services (IIS), right mouse click the GViewer Virtual Directory, select the ‘Virtual Directory’-tab and then select the ‘Configuration’-tab which shows the ‘Application Configuration’ dialog. Make sure you select both checkboxes in the ‘Debugging flags’ section.
We also need to let ASP.Net compile webpages with debugging enabled. For IIS, ASP.Net is just a plugin to handle pages with an .aspx extension and it’s configuration is apart from IIS. In order for ASP.Net to generate debugging symbols when your pages are compiled, you need to add the following line to Web.Config located in
C:\Program Files\Intergraph\GTechnology\Program\GViewerApp, just after the system.web node:

  <compilation debug="true" />

Debugging should now work. If you select button ‘Attach’ from the ‘Attach to process’ screen, invoke a clientside function which posts back to your server page your breakpoints should be hit :

Breakpoint hit Netviewer aspx page

Breakpoint hit Netviewer aspx page

The ‘Single File Page’ model

One thing which also might help is to develop your ASPX-pages with all your server-side code in the aspx page itself. That way, you don’t need to place a custom dll in the GViewerApp bin folder and temper with it. This technique is called the Single File Page Model, an aspx-page using this technique looks like this :

<%@ Page Language="C#" %>

<script type="text/C#" runat="server">
    protected void Page_Load(object sender, EventArgs e)

    protected void Button1_Click(object sender, EventArgs e)
        this.Label1.Text = "Netviewer Rocks!";
<html xmlns="">
<head runat="server">
    <form id="form1" runat="server">
        <asp:Button ID="Button1" runat="server" OnClick="Button1_Click" Text="Button" />
        <asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>

You need to place this file in the GViewerApp folder. If you now attach Visual Studio to process ‘w3wp.exe’ and open your .aspx file, your breakpoints will be hit :

Breakpoint hit single file model Intergraph Netviewer server

Breakpoint hit single file model

In my experience, that’s the most convenient way to debug ASPX pages. You just need to place the .aspx-page in the GViewerApp folder, attach Visual Studio to the w3wp.exe process and you’re ready to go. You can also change code in the aspx without having to restart the server, ASP.Net will recompile it runtime.


  • If using the code-behind model, you might need to restart GNetviewer for the breakpoints to be hit and to be able to overwrite files in the GViewerApp\bin folder
  • If the process ‘w3pw.exe’ doesn’t show up in the process list and Netviewer is started, there is no session yet. You need to start Netviewer client for new HTTP requests to be send to IIS which will start a new worker process ‘w3wp.exe’. This is your new session.
  • In order to quickly see if your breakpoints are hit, you can enter a url like http://g01/GViewer/QuickSearch.aspx directly in Internet Explorer. If you then select a button causing a postback and your environment is setup right, breakpoints are hit and you can step through your code
  • When attaching the debugger, you may need to select the type of code to debug. Visual Studio doesn’t always select the right type :
    Select code type to debug

    Select code type to debug

  • If you have a aspx-page outside of the GViewerApp application, you need to copy it for your changes to take effect, which leaves you with 2 versions of a file. You can avoid this by creating a symbolic link from your copy to your source :
    $fsutil hardlink create DekkingsProfiel.aspx "C:\Users\Stephan\Wrk\sde01_one\Gasunie\Ga

    Windows now creates a symbolic link to your source-aspx, and it looks like there are 2 seperate aspx-files, but if you edit either one of them both are changed since there’s really only one version. This way, the version in in GViewerApp always matches your development version.

Debugging Oracle PL/SQL from Visual Studio

Product components (lower part)

I use TOAD for my day-to-day Oracle development, but I find it’s debugging experience very poor compared to Visual Studio. Using ODP.Net version 11 you can use Visual Studio to debug Oracle PL/SQL. Here’s how to do it.

First you need to install ‘Oracle Data Access Components for Oracle Client’ or higher. You can download this from Oracle and you should get file Extract the file and double click setup.exe. After this, you’ll see the following screen :

Oracle Data Access Components for Oracle Client

Oracle Data Access Components for Oracle Client

Select ‘Oracle Data Access Components for Oracle Client’ as done in the screen and select ‘Next’. The ‘Available Product Components’-screen shows up :

Product components (upper part)

Product components (upper part)

Product components (lower part)

Product components (lower part)

You only need so select the following :

  • Oracle Data Provider for .Net
  • Oracle Developer Tools for Visual Studio
  • Oracle Instant Client

Note:You probably don’t need the ‘Oracle Instant Client’ since you already got sqlplus, but the installer won’t let you deselect it. Select next and let the software install.

After you have installed it, you need to modify the new installed tnsnames.ora which is empty. I just created a symbolic link from to my original tnsnames.ora, that way I only need to maintain one (1) single tnsnames.ora. You can create junctions with the mklink windows command or the junction tool from sysinternals.

Once this is done, you should be able to debug Oracle PL/SQL code using Visual Studio.

I have installed a local Oracle XE database with a G/Technology instance on it, and I want to step through package GPTUtils.PostProcess (‘COMPONENT’).

Connect to your server

From within Visual Studio 2010, open Server Explorer (View->Server Explorer)  and right mouse click ‘Data Connections’ and select the ‘Add Connection’ entry :

Data Connections

The ‘Add Data Connection’-dialog appears. On the ‘Add Data Connection’ dialog, enter the credentials for your Oracle instance and hit ‘Test Connection’ to check it :

Add Dataconnection

After you verified Visual Studio was able to connect to your database, close the ‘Add Data Connection’ dialog and expand the server explorer node with your packages :

Browse packages

Debug GPTUtils.PostProcess

We now want to enter package GPTUtils.PostProcess(‘COMPONENT’) to see what it actually is doing, so I browse to package ‘GPTUtils’, right mouse click method ‘PostProcess’ and select ‘Run debug’. The ‘Run Procedure’-dialog appears enabling you to enter arguments. Enter ‘COMPONENT’ and hit ‘OK’:

Run procedure

Run procedure

A debug session is now started and you can view the call stack, set breakpoints, evaluate variables and use Visual Studio keyboard shortcuts :

GPTUtils.PostProcess (‘COMPONENT’) debugged

‘DBMS_OUTPUT.PUT_LINE’ statements are written to your output window, but they not immediately visible and you need to select the right output. Despite this, I find the Visual Studio debugging experience much more better and productive compared to TOAD’s one.

Some additional notes :

  • To be able to debug your PL/SQL code, you need to have it compiled with debug information. If you haven’t, Visual Studio will ask you to do this.
  • You need to have a static ipadress. I used the Micosoft Loopback adapter.
  • Any existing Oracle connections will need to be recreated

My software configuration looks like this :

  1. Windows 7 64 bit
  2. Oracle11R2g XE 32 bit (file
  3. Visual Studio 10 Service pack 1
  4. ODP.Net, 32 bits (file