NetQuarry is an enterprise application software platform for Microsoft.NET. It is comprised of pre-built software, metadata and tools designed to help professional software teams develop significantly better enterprise and hosted business applications. Developers using NetQuarry will deliver everything faster (less time and manpower equals less cost).

  • Rapid Prototypes (five to ninety days)
  • Initial functional applications that perform like highly mature ISV solutions
  • Subsequent versions and improvements without major rewrites.

And the applications developed on NetQuarry will perform better in a demanding hosted and enterprise environment.

Key Benefits:

  • Rapid results/development cycle
  • High product functionality with low project execution risk
  • Low ownership cost
  • Low maintenance cost
  • Low hardware cost
  • Rich functionality for customization

NetQuarry provides a foundation of functionality common to virtually all enterprise class applications. The common functionality includes data binding, database virtualization, OS-virtualization, searching, filtering, user interface (UI), security / permissioning, and numerous other commonly required capabilities. In each case the features are designed with great attention to the enterprise-class foundation, and with the knowledge of what custom applications, the developers and users of those applications really need.

One of the key concepts of the NetQuarry product is its extensibility. Although from past experience we understand most of the commonly required features; we also know that we cannot anticipate or accommodate all custom application needs. For this reason NetQuarry provides a comprehensive extension model. This model allows extension to the basic functionality through creation of .NET-compatible components that are configured into the system to respond to system events. This model makes NetQuarry an excellent platform not just for new application development, but also for Enterprise Application Integration (EAI). Using NetQuarry, multiple external applications can be integrated into a single front-end. In addition, because of the meta-data used to specify Business Objects in NetQuarry, NetQuarry can provide SOAP and Service Oriented Architecture (SOA) definitions.

Some of the most signficant objects in the platform are:

  • IAppContext - The application context object.
  • IDatabase - The database object.
  • IMapper - The Object Relational Mapping (ORM) object generally corresponding to a table or view.
  • IField - Items within an IMapper generally corresponding to a table/view column.
  • PageInfo - The application page defintion object.
  • PageElementInfo - Items within a PageInfo object corresponding to various data display elements on the page.
  • Navigator - An object describing navigation a collection of links within the application.
  • NavTarget - The individual navigation items within an Navigator.
  • IExtension - The primary event-based programming object interface.
Standard platform scheduled tasks.


The NetQuarry Enterprise Application Platform (EAP) allows you to build and deploy n-tiered, enterprise quality applications. The EAP sits on the Microsoft .NET common language runtime and provides rich functionality at all layers of an application.

The NetQuarry EAP does not generate code, rather, it uses the NetQuarry Core Runtime, custom configuration, metadata, and developer coded extensions to construct world class, quality applications.

Data Sources

Business applications depend on data. Increasingly, this data comes from multiple data “sources” across the enterprise. These sources of data may exist in relational databases such as Oracle, Microsoft SQL Server, or IBM DB2. Some of the sources of data, however, exist as Web Services, XML documents, or remote procedure calls. NetQuarry makes aggregating disparate data into a single, functional user interface simple and fast.


Extensions are a key concept of the NetQuarry platform. Extensions are libraries that receive events from the running application objects. For example, when a record in a page is changed, the IMapper representing that data fires update events (notifications) through all of the extensions configured (via metadata) on that object.

This is a powerful programming pattern that is extremely simple for application developers, even those unfamiliar with Microsoft .NET to quickly grasp and master.

To create an extension, the developer can run a wizard from the Studio that allows them to specify the name, location, language (C#, VB.NET), and which objects they want to attach the extension.

Some objects support the idea of “global” extensions (e.g. Mapper-based objects). A global extension is automatically attached to all objects of a particular class. This is particularly useful for functionality such as auditing and summary information handling.

Extensions must implement a known interface (IExtension) or derive from a provided base class. The most common type of extension is the mapper extension which typically derives from MapperExtensionKernel or TypedMapperExtension). Most non-declarative business logic is implemented in mapper extensions. Most applications also include a small number of page extensions (derived from PageExtensionBase for handling wizard and console page events, and a single application extension (derived from ApplicationExtensionBase).


The following example shows an extension that handles a RowBeforeUpdate event on a Mapper.
C# Copy imageCopy
using System;
using NetQuarry;        // Include the NetQuarry objects

namespace XCustomer
    public class XExt : MapperExtensionKernel
        public XExt() {}

           public override void RowBeforeUpdate(IMapper sender, NQEventArgs e)
            IField        fld = sender.Fields["forecast_discount_amount"];

            if (System.Convert.ToInt32(fld.Value) > 10)
                fld.Value = 10;

Handling business logic using this methodology is both simple and robust. Extensions can be reused across multiple objects, they can be debugged interactively using Visual Studio, and they hide the complexity of the infrastructure from the application developer allowing them to concentrate on the task of building business applications.


A Mapper (IMapper) is the primary means of mapping object-oriented programming objects to data sources managed by relational databases or other sources of data. A Mapper provides 2-way (Read and Write) access to the underlying Data Source.

There are several subclasses of the Mapper object. The most important are the MapperDatasheet and MapperDetail. Each provides an implementation that uses the data in the Mapper to render a view of the data using HTML.

Application (IAppContext)

The Application object holds information that is used throughout each page (or server) request. The Application is available to all objects, most importantly the extensions. The Application object is created as the first object in any request, and when possible it is cached for performance purposes.

The Application object handles connecting to the authentication provider, authenticating the user, checking object permissions for that user, storing user (UserContext) information, holding the list of available PageInfo objects, and connecting to the metadata (Repository) data source. It also has a collection of DataSources specified in metadata.

More than one Application object may be specified in metadata, and connecting to an application allows the user to see more than one “view” of an implemented NetQuarry application.

Pages and Templates

A Page is the smallest object that renders user interface. Some pages display data from a IMapper, while others allow the user to perform a quick search, quick creation of an object, or perform some sort of navigation.

A Template is a code-based layout of one or more areas (called Slots). Each slot in a template is specified using a Page property at design time.

Properties and TextItems

Many NetQuarry platform objects support a collection of custom Properties. Properties are fields of information that varies between objects and object instances. Most properties are loaded from the metadata when the object is created. A property that is loaded from metadata has an associated parameter object (a metadata only object) defined in the metadata. Properties can be added at runtime or design time. At design time, parameters form the definition for the NetQuarry studio’s property sheet.

TextItems are similar to properties but hold only strings. Additionally, each TextItem object is specific to a locale (or culture). At runtime, Textitems are loaded for the current user’s culture. If there is no string for the type of text for the current culture, the default culture is used. All strings used in the platform are represented as TextItems. This provides a simple way to support multiple user languages (cultures) on a single site, with a single codebase.

Properties and TextItems provide programmatic access to virtually all meta-data associated with an object.


The platform is proactively logging a rich set of data to help the developer diagnose problems during development and runtime. Additionally, the developer can use the built-in object called DevLog to add messages to the log.

Using Mappers

If you create a resource that has a connection to a database (IDatabase) object such as a Mapper, you must close the Mapper before exiting the procedure.


Generated TypedMapper derived classes are useful when manipulating a mapper and you would like to treat it more like a type-safe object. They are also useful as a base class for higher level business objects that you may require in your extensions. A TypedMapper has a Get and Set property for every field defined in the mapper. If you have fields with an include flavor you may need to add a Get and Set property in your derived class as the generator will not pickup these fields.

You typically use a TypedMapper in your extensions. You can create a TypedMapper and attach it to the sender (IMapper) of the event or you can use the TypedMapper derivative to create a new mapper - either for the purpose of creating a new row or reading/updating an existing one. Connecting a TypedMapper via one of the constructors or TypedMapper.Attach is very inexpensive and generally a safer way to work with a mapper. You should, however, use good judgement when creating a new instance of a TypedMapper as a query of the operational database is generally required.

Generating TypedMappers

To generate typed mappers you run the command line utility EAP.Tools.CodeGen.EXE installed in the <application root>/bin folder. The utility takes the following arguments (the first argument (-AppID) is required):

  1. -AppID:<appid> - the ID for your application.
  2. -CamelCase - (optional) include this to convert property names to a CamelCase representation. By default, property names are the same as the mapper field's key name
  3. -NullableNumerics - (optional) include this to declare the numeric field properties as Nullable. By default, numeric properties are defined as their value types and 0 (or false) is returned if the value is null.
  4. -NoNullStrings - (optional) include this to force string properties to return an empty string instead of null when the field value is null. By default, null values are returned as null strings.
You must create a config section in the EAP.Tools.CodeGen.exe.config with the options. Example:
 Copy imageCopy
    <section name="IssueTrak" type="System.Configuration.NameValueSectionHandler" />

 <!-- connection strings -->
 <add key="repository_connect" value="Provider=SQLOLEDB;Data Source=.;Initial Catalog=issues_meta;Integrated Security=SSPI" />    
 <add key="IssueTrak_connect" value="Provider=SQLOLEDB;Data Source=.;Initial Catalog=issues_data;Integrated Security=SSPI" />

 <!-- optional, normally set by the web application context -->
 <add key="RootPath" value="c:\inetpub\wwwroot" />
 <add key="RootURL" value="http://localhost" />

 <!-- full path to the file to be generated -->
 <add key="GeneratedFileName" value="C:\NetQuarry\IssueTrak\Source\Data\Generated\TypedMappers.cs" />
 <!-- namespace to use for the generated TypedMapper classes -->
 <add key="Namespace" value="IssueTrak.Data" />


 Copy imageCopy
EAP.Tools.CodeGen -AppID:%APP_KEY% -CamelCase -NoNullStrings

The NetQuarry platform provides a full-featured export facility for exporting list (Datasheet) data to Microsoft Excel spreadsheets. The export functionality is exposed in the application UI via the ExcelExport mapper extension.
The NetQuarry platform provides many standard UI elements required in a web application.
The NetQuarry service providing diagnostic information of system performance and errors.
The NetQuarry GoogleGeocoder namespace provides objects used by the platform for geocoding (converting addresses to longitude/latitude) and reverse-geocoding (converting longitude/latitude to an address) using Google Maps.
NetQuarry provides support for HTML5 controls by extending existing controls such as the standard .Net TextBox. Using these HTML5 controls provides the browser with additional information about how the control is used allowing the browser to provide the best possible user experience. For example, on an Apple iPad using the Tel control will cause the iPad to present a keyboard suitable for telephone number entry when the user click on an editable Tel control.
The NetQuarry platform provides a sophisticated email facilities including support for:
  • Attachments
  • Relationships
  • No-send list
  • Template mailings
  • SendGrid integration

The Metadata namespace holds classes used to manage the NetQuarry metadata.

The Net namespace holds helper and extension classes used for working with .Net HTTP objects such as HttpRequest, HttpUtility, and IHttpHandler.
The NetQuarry platform supports a full-text parsing syntax based on the Irony parsing engine.
The NetQuarry platform supports SQL-Server Reporting Services (SSRS) reports as well as native list reports. SSRS report support includes support for sub-reports and various platform facilities including sub-reports, application vocab, and Picklist use.

As of SQL-Server Reporting Services for Sql-Server 2014, .Net framework 4.0 is NOT supported. So, in order to support applications built on .Net framework 4.0 (or later) the platform provides a COM Interop bridge.

Provides definitions and utilities for supporting scanners.
NetQuarry supports application security using a powerful, replaceable set of authentication and permission patterns. Depending on the needs of your application and the capabilities of your enterprise infrastructure, NetQuarry can support several different methods of user authentication.
The NetQuarry application permissioning model based on functionality grouped in packages.

The services namespace provides runtime services, such as email processing, alert management, and task-scheduling.

Services are defined in metadata and can contain properties for configuration. A Service references a component and that component must implement the IServiceInfo interface.

Services can be marked as Singleton. This means that the application context object will create only one instance of the service for the life of the application.

The NetQuarry service for logging exceptions using Bugsnag.
The NetQuarry service providing payment integration with BrainTree.
The NetQuarry service for creating recurring payments and charging payments via the PayPal Website Payments Pro API.
The NetQuarry service for sending and receiving messages using Slack.
The NetQuarry service providing email verification via integration with
The Threading namespace holds classes used for thread management.
The NetQuarry platform provides several built-in charting capabilities base on 3rd party charting engines.
The Util namespace holds certain infrequently used utility classes.
Provides image manipulation utilities via the ImageManager class.
The Web.Services namespace holds helper classes used for supporting seb services.
The NetQuarry platform provides a number of custom WebControls for use in platform-based applications.

The SystemProperties namespace contains marker interfaces used for documentation purposes only. These interfaces are not available in the release versions of NetQuarry.

Properties with an underscore in their name (e.g. FieldProperties) are named this way to prevent collision. There are actually duplicate parameters defined in the metadata with sub-types that cause the NetQuarry Studio to distinguish between them based on the type of the object.