Jun 032014
 

One of the problems that we see at my work, often on a newly created development box, is that you can launch ArcMap from the debugger, but can’t break and examine code and objects.  The problem for this often lies in the ArcMap.exe.config file.  You must allow for the proper version of the .NET runtime in the config file.  Without it, the CLR won’t load the right runtime and debug symbols won’t align with the code you are running.

To fix this, edit the ArcMap.exe.config file, which is located at: C:\Program Files (x86)\ArcGIS\Desktop10.2\bin.  This post is for ESRI’s ArcMap, but it applies globally to all Windows exes that utilize .NET framework assemblies.

To run/debug against the 4.0 .NET framwork, make sure that you have this line in the ArcMap.config.exe file and you will be good to go:
<supportedRuntime version=”v4.0.30319″/>

You can read more about this from Microsoft in these two articles:

Apr 302014
 

Don’t Repeat Yourself, or DRY, is a key principle of software engineering.  Various sites on the web and various courses state this principle as

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

One of the things this means, practically, is that the abstractions that you use in your code should provide for reuse such that there is never a need to copy code.

Reuse of code can be accomplished by properly designing your objects (abstractions) such that they have a single responsibility.  For example, if you have several objects that communicate with a data layer, you should abstract the data layer away into a data access class that is then injected into the constructor of objects that need to converse with the data layer.  This provides for better data encapsulation and allows for better unit testing as you can create a fake for the data access object.  Another example of how you can reuse code is through the use of base classes that provide functionality that is common to a set of potentially derived classes.

I recently presented a course on best practices for Object Oriented Design at my company and ran across a very cool tool that was mentioned in a Pluralsight course by Steve Smith.  The tool is Atomiq by goldfinch.  It is a completely free tool that they make available (self-admitedly) to drum up business for their static analysis tool, Nitriq.  Atomiq searches your code and finds code duplication and similarities.  It provides statistics and and easy way to navigate to duplications within the code.  It provides a very nifty graphic to show where duplicates are and it even has a command line exe for which a threshold can be set for use with a continuous integration builder (very cool!).

I decided to test drive Atomiq using some old code to which I had access.  I knew this code would give Atomiq a run for its money as this code has been around for a decade and has been touched and tweaked and, well, defiled by many developers.  After letting Atomiq analyze the entire project, this is the wheel graphic that was generated by Atomiq:

Wheel Output From Atomiq For Solution with Lots of Repetition

Wheel Output From Atomiq For Solution with Lots of Repetition – (Class Names Removed to Protect the Innocent)

As I suspected, Atomiq found many sources of repetition in this solution.  Each line crossing this Spirograph looking picture represents an opportunity to refactor this code such that the repetition goes down and the maintainability goes up.

I had another project where I was playing around prototyping a couple ICommand objects for use in ESRI’s ArcMap.  In this project, the two commands were generated using the ArcMap ICommand generation tool in Microsoft Visual Studio.  Because the classes were auto-generated, the same base code was added to each.  For example, this code (along with a few other lines) was auto-generated into both classes:


#region COM Registration Function(s)
[ComRegisterFunction]
[ComVisible(false)]
static void RegisterFunction(Type registerType)
{
    // Required for ArcGIS Component Category Registrar support
    ArcGisCategoryRegistration(registerType);
}

[ComUnregisterFunction]
[ComVisible(false)]
static void UnregisterFunction(Type registerType)
{
    // Required for ArcGIS Component Category Registrar support
    ArcGisCategoryUnregistration(registerType);
}
#endregion

This duplicated code caused Atomiq to (rightly) generate this graph:

Atomiq Output Because of Duplicate Auto-Generated ICommand Template Code

Atomiq Output Because of Duplicate Auto-Generated ICommand Template Code

For this particular duplication, Atomiq found 65 lines that were similar.  Also, Atomiq showed this similarity view, that showed the same code side-by-side:

Atomiq Similarity View Showing ESRI ICommand Boilerplate

Atomiq Similarity View Showing ESRI ICommand Boilerplate

This is one example where Atomiq shows a great place to do some refactoring.  By pulling all of the ESRI ArcMap boilerplate code into a base class, we can move all of this duplicate code to one place and then create derived classes from this base class.  For this example, I just started by refactoring out a part of the similar code, as shown here:


using ESRI.ArcGIS.ADF.BaseClasses

// Base class from which all other ESRI ICommands should be derived for code reuse

[ComVisible(true)]
public abstract class MyBaseCommand : BaseCommand
{
    [ComRegisterFunction]
    [ComVisible(false)]
    static void RegisterFunction(Type registerType)
    {
        // Required for ArcGIS Component Category Registrar support
        ArcGisCategoryRegistration(registerType);
    }

    [ComUnregisterFunction]
    [ComVisible(false)]
    static void UnregisterFunction(Type registerType)
    {
        // Required for ArcGIS Component Category Registrar support
        ArcGisCategoryUnregistration(registerType);
    }

    // Move other common ICommand code here

}

After reanalyzing the code, the 65 similar lines dropped to 55:

After refactoring - Duplicate Lines Dropped from 65 to 55

After refactoring – Duplicate Lines Dropped from 65 to 55

By iterating in this same fashion, Atomiq can help to eliminate duplications and make this code more maintainable.

While there is no silver bullet, Atomiq is a very good (and very free) tool to use in making sure that you write code that complies with the DRY principle.  When coupled with the command line version for a continuous integration builder, this is a great way to improve code quality.

Sep 272013
 

I have worked with GIS systems for many years now, working with both ESRI, Intergraph, and Bentley (if you count that MicroStation class I took in college) systems.  Sometimes when you are working on client-side code, it is useful to see the actually calls from the client back to the database.  One of the most useful and simple tools that I have found when working with ESRI’s ArcMap is to set up an SDE intercept.  By doing this, intercept files are generated on the client machine that contain very verbose output pertaining to every transaction with the undrelying geodatabase.  The output can be overwhelming, but it can also be very revealing.

Setting up the intercept is very easy.  You only need to add 2 environment variables to your system.  The following are the variables and their values:

  • SDEINTERCEPTLOC = c:\temp\<the subfolder you created to contain intercept files>
  • SDEINTERCEPT = crwtf

You could also set these up with a bat file if you want.

After you have set these environment variables, run ArcMap and the workflow that you want to examine.  You can then investigate the log generated to diagnose your issue.

Be sure to remove these environment variables when you are finished.  The output is very verbose and can quickly fill up your hard drive!